Kafka Rebalance
在处理消息积压的问题时，常见的方案之一为增加 partition 数量，但是此时会触发 rebalance，在某些配置条件下会短暂阻塞消费，同时由于分区的消费者可能发生切换，消息消费的顺序性需要重新考量
Rebalance 触发机制¶
一般在三种情况下触发：
-
主题下的 partition 数量发生变化，如分区数增加时
-
消费者组内成员数量发生变化
- 新的消费者加入 consumer group 时
- 消费者离开 consumer group 时，如正常关闭或崩溃
Rebalance 的过程¶
- 暂停消费（防止 rebalance 时出此案数据丢失或重复）
- 由一个 broker 充当 coordinator，触发 rebalance
- coordinator 挑选一个消费者作为 group leader，由 leader 根据分配策略决定每个分区分给哪个消费者
- coordinator 下发最新的分配结果给每个消费者
- 恢复消费
分区策略¶
分区策略通过 partition.assignment.strategy 这个配置进行设置
Range Assignor¶
以 topic 为单位，按照分区的编号将分区划分给消费者，每个消费者分配连续的分区
RR Assignor¶
将消费者组负责的所有 topic 中的所有 partition 按照 (topic, partition) 进行偏序排序，最后几个 consumer 轮流交错进行认领，如：
- c1: a0, a2, b1, b3
- c2: a1, b0, b2
Sticky Assignor¶
在保证均衡分配的同时，尽可能多地保留原有的分配
在这个配置下，最初的一次原始分配按照 RR 进行，后面在均衡的同时，减少分区分配的移动
CooperativeStickyAssignor¶
在分配层面上的策略和 StickyAssignor 保持一致，实际的 reblance 的执行过程不同
不会一次性全部分配好，而是进行渐进式地分配
Eager / Incremental Rebalance¶
上述分区策略中，前三个都是 eager rebalance，在 rebalance 发生的过程中，整个消费者组停止消费任何消息，出现 stop the world
CooperativeStickyAssignor 是在 2.3 版本之后引入的优化方案，在 rebalance 的过程中部分分区从一个消费者移动到另一个消费者，其他不涉及的消费者可以继续进行消费。付出的代价则是 rebalance 的时间会更久，因为在整个均匀化的过程中，不止涉及到一次的移动操作