Package org.apache.kafka.clients.consumer

Class RangeAssignor

java.lang.Object
org.apache.kafka.clients.consumer.internals.AbstractPartitionAssignor
org.apache.kafka.clients.consumer.RangeAssignor
All Implemented Interfaces:
ConsumerPartitionAssignor
public class RangeAssignor extends org.apache.kafka.clients.consumer.internals.AbstractPartitionAssignor

The range assignor works on a per-topic basis. For each topic, we lay out the available partitions in numeric order and the consumers in lexicographic order. We then divide the number of partitions by the total number of consumers to determine the number of partitions to assign to each consumer. If it does not evenly divide, then the first few consumers will have one extra partition.

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, t0p1, t1p0, t1p1]
  • C1: [t0p2, t1p2]
Since the introduction of static membership, we could leverage group.instance.id to make the assignment behavior more sticky. For the above example, after one rolling bounce, group coordinator will attempt to assign new member.id towards consumers, for example C0 -> C3 C1 -> C2.

The assignment could be completely shuffled to:

  • C3 (was C0): [t0p2, t1p2] (before was [t0p0, t0p1, t1p0, t1p1])
  • C2 (was C1): [t0p0, t0p1, t1p0, t1p1] (before was [t0p2, t1p2])
The assignment change was caused by the change of member.id relative order, and can be avoided by setting the group.instance.id. Consumers will have individual instance ids I1, I2. 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, t0p1, t1p0, t1p1]
  • I1: [t0p2, t1p2]