You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+58-19
Original file line number
Diff line number
Diff line change
@@ -747,47 +747,86 @@ end
747
747
#### Customizing Partition Assignment Strategy
748
748
749
749
In some cases, you might want to assign more partitions to some consumers. For example, in applications inserting some records to a database, the consumers running on hosts nearby the database can process more messages than the consumers running on other hosts.
750
-
You can use a custom assignment strategy like below:
750
+
You can use a custom assignment strategy by passing an object that implements `#call` as the argument `assignment_strategy`like below:
751
751
752
752
```ruby
753
-
Kafka::ConsumerGroup::Assignor.register_strategy(:custom) do |cluster:, members:, partitions:|
754
-
# strategy goes here
753
+
classCustomAssignmentStrategy
754
+
definitialize(user_data)
755
+
@user_data= user_data
756
+
end
757
+
758
+
# Assign the topic partitions to the group members.
759
+
#
760
+
#@paramcluster[Kafka::Cluster]
761
+
#@parammembers[Hash<String, Kafka::Protocol::JoinGroupResponse::Metadata>] a hash
762
+
# mapping member ids to metadata
763
+
#@parampartitions[Array<Kafka::ConsumerGroup::Assignor::Partition>] a list of
764
+
# partitions the consumer group processes
765
+
#@return[Hash<String, Array<Kafka::ConsumerGroup::Assignor::Partition>] a hash
`members` is a hash mapping member ids to metadata, and `partitions` is a list of partitions the consumer group processes. The block should return a hash mapping member ids to partitions.
760
-
For example, the following strategy assigns partitions randomly:
776
+
`members` is a hash mapping member IDs to metadata, and partitions is a list of partitions the consumer group processes. The method `call` must return a hash mapping member IDs to partitions. For example, the following strategy assigns partitions randomly:
761
777
762
778
```ruby
763
-
Kafka::ConsumerGroup::Assignor.register_strategy(:custom) do |cluster:, members:, partitions:|
764
-
member_ids = members.keys
765
-
partitions.each_with_object(Hash.new {|h, k| h[k] = [] }) do |partition, partitions_per_member|
If the strategy needs user data, you can pass the option`user_data`, a proc that returns user data on each consumer:
789
+
If the strategy needs user data, you should define the method`user_data`that returns user data on each consumer. For example, the following strategy uses the consumers' IP addresses as user data:
772
790
773
791
```ruby
774
-
Kafka::ConsumerGroup::Assignor.register_strategy(:custom, user_data:->{ ... }) do |cluster:, members:, partitions:|
As the method `call` might receive different user data from what it expects, you should avoid using the same protocol name as another strategy that uses different user data.
828
+
829
+
791
830
### Thread Safety
792
831
793
832
You typically don't want to share a Kafka client object between threads, since the network communication is not synchronized. Furthermore, you should avoid using threads in a consumer unless you're very careful about waiting for all work to complete before returning from the `#each_message` or `#each_batch` block. This is because _checkpointing_ assumes that returning from the block means that the messages that have been yielded have been successfully processed.
0 commit comments