《Apache Kafka 实战》读书笔记-消费者重平衡（rebalance）剖析
作者：尹正杰
版权声明：原创作品，谢绝转载！否则将追究法律责任。
一.rebalance简介
consumer group的rebalance本质上是一组协议，它规定了一个consumer group 是如何达成一致来分配订阅topic的所有分区的。假设某个组下有20个consumer实例，该组订阅一个有着100个分区的topic。正常情况下，Kafka会为每个consumer平均分配5个分区。这个分配过程就被称为rebalance。
当consumer成功执行rebalance后，组订阅topic的每个分区只会分配给组内一个consumer实例。换句话说，同一个消费者组的消费者不能同时对同一个topic的同一个分区进行消费。
和旧版本consumer依托于zookeeper进行rebalance不同，新版本consumer使用了Kafka内置的一个全新的协议（group coordination protocol）。对于每个组而言，Kafka的某个broker会被选举为组协调者（group coordinator）。coordinator负责对组对状态进行管理，他的主要责任就是当新成员到达时促成组内所有成员达成新对分区分配方案，即coordinator负责对组执行rebalance操作。
二.rebalance触发条件
组rebalance触发对条件有以下3个：
第一：组成员发生变更，比如新consumer加入组，或已有consumer主动离开组，再或是已有consumer崩溃时则触发rebalance；
第二：组订阅topic数发生变更，比如使用基于正则表达式对订阅，当匹配正则表达式对新topic被创建时则会触发rebalance；
第三：组订阅topic时分区发生变更，比如使用命令行脚本增加了订阅topic的分区数；
真实应用场景引发rebalance最常见的原因就是违背了第一个条件（比如flume的kafka source相对于broker集群来说就是consumer对象），特别是consumer崩溃的情况。这里的崩溃不一定就是指consumer进程“挂掉”或consumer进程所在的机器宕机。当consumer无法在指定的时间内完成消息处理，那么coordinator就认为该consumer已经崩溃，从而引发新一轮rebalance。
我在生产环境中也使用flume消费kafka的数据到hdfs集群上，也遇到过这种rebalance的情况，最终分析原因是：该group下的consumer处理消息的逻辑过重，而且事件处理时间波动很大，非常不稳定，从而导致coordinator会经常行的认为某个consumer已经挂掉，引发rebalance。鉴于目前一次rebalance操作的开销很大，生产环境中用户一定要结合自身业务特点仔细调优consumer参数：“request.timeout.ms”,“max.poll.records”和“max.poll.interval.ms”这几个参数，以避免不必要的rebalance出现。
三.rebalance 分区分配
四.
五.