public class RoundRobinAssignor
extends org.apache.kafka.clients.consumer.internals.AbstractPartitionAssignor
The round robin assignor lays out all the available partitions and all the available consumers. It then proceeds to do a round robin assignment from partition to consumer. If the subscriptions of all consumer instances are identical, then the partitions will be uniformly distributed. (i.e., the partition ownership counts will be within a delta of exactly one across all consumers.)
For example, suppose there are two consumers C0 and C1, two topics t0 and t1,
and each topic has 3 partitions, resulting in partitions t0p0, t0p1, t0p2,
t1p0, t1p1, and t1p2.
The assignment will be:
C0: [t0p0, t0p2, t1p1]
C1: [t0p1, t1p0, t1p2]
When subscriptions differ across consumer instances, the assignment process still considers each
consumer instance in round robin fashion but skips over an instance if it is not subscribed to
the topic. Unlike the case when subscriptions are identical, this can result in imbalanced
assignments. For example, we have three consumers C0, C1, C2,
and three topics t0, t1, t2, with 1, 2, and 3 partitions, respectively.
Therefore, the partitions are t0p0, t1p0, t1p1, t2p0, t2p1, t2p2.
C0 is subscribed to t0;
C1 is subscribed to t0, t1;
and C2 is subscribed to t0, t1, t2.
That assignment will be:
C0: [t0p0]
C1: [t1p0]
C2: [t1p1, t2p0, t2p1, t2p2]
group.instance.id to make the assignment behavior more sticky.
For example, we have three consumers with assigned member.id C0, C1, C2,
two topics t0 and t1, and each topic has 3 partitions, resulting in partitions t0p0,
t0p1, t0p2, t1p0, t1p1, and t1p2. We choose to honor
the sorted order based on ephemeral member.id.
The assignment will be:
C0: [t0p0, t1p0]
C1: [t0p1, t1p1]
C2: [t0p2, t1p2]
member.id towards consumers,
for example C0 -> C5 C1 -> C3, C2 -> C4.
The assignment could be completely shuffled to:
C3 (was C1): [t0p0, t1p0] (before was [t0p1, t1p1])
C4 (was C2): [t0p1, t1p1] (before was [t0p2, t1p2])
C5 (was C0): [t0p2, t1p2] (before was [t0p0, t1p0])
I1, I2, I3. As long as
1. Number of members remain the same across generation
2. Static members' identities persist across generation
3. Subscription pattern doesn't change for any member
The assignment will always be:
I0: [t0p0, t1p0]
I1: [t0p1, t1p1]
I2: [t0p2, t1p2]
org.apache.kafka.clients.consumer.internals.AbstractPartitionAssignor.MemberInfoConsumerPartitionAssignor.Assignment, ConsumerPartitionAssignor.GroupAssignment, ConsumerPartitionAssignor.GroupSubscription, ConsumerPartitionAssignor.RebalanceProtocol, ConsumerPartitionAssignor.Subscription| Modifier and Type | Field and Description |
|---|---|
static String |
ROUNDROBIN_ASSIGNOR_NAME |
| Constructor and Description |
|---|
RoundRobinAssignor() |
| Modifier and Type | Method and Description |
|---|---|
Map<String,List<TopicPartition>> |
assign(Map<String,Integer> partitionsPerTopic,
Map<String,ConsumerPartitionAssignor.Subscription> subscriptions) |
String |
name()
Unique name for this assignor (e.g.
|
assign, assignPartitions, partitionInfosWithoutRacks, partitions, put, useRackAwareAssignmentclone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, waitgetAssignorInstances, onAssignment, subscriptionUserData, supportedProtocols, versionpublic static final String ROUNDROBIN_ASSIGNOR_NAME
public Map<String,List<TopicPartition>> assign(Map<String,Integer> partitionsPerTopic, Map<String,ConsumerPartitionAssignor.Subscription> subscriptions)
assign in class org.apache.kafka.clients.consumer.internals.AbstractPartitionAssignorpublic String name()
ConsumerPartitionAssignorConsumerConfig.PARTITION_ASSIGNMENT_STRATEGY_CONFIG