前言

所谓Rebalance就是让Consumer对如何消费订阅主题下的分区进行重新规划，由于整个过程所有Consumer都不能消费，因此Rebalance的发生次数以及一次Rebalance的持续时间都对Consumer有着很大的影响。

触发Rebalance的原因

1. 消费者成员发生变化

这应该是最常见的触发Rebalance的原因，比如：服务发布重启，就会造成消费者成员发生变化，一般而言这种场景是正常的需求，不必太过注意。

为了保证消费者组的可用性，Kafka中的Coordinator组件会负责监测所有Consumer的存活性，其判定方式是通过每个Consumer定期给它发送心跳来确定的，参数为session.timeout.ms，其默认值是10秒，也就是一旦Consumer超过10秒没有给Coordinator发送心跳，Coordinator就认为Consumer发生故障，此时Coordinator的做法就是将其从消费者组中移除，从而引发Rebalance，当然这本身是一个良好可用性的保障，只不过如果因为其他原因导致Consumer无法发送心跳而引起Rebalance就非其本意了，一般线上环境上最容易导致心跳无法发送的场景就是：长时间的GC暂停、CPU使用过高。

综上所述，对于session.timeout.ms配置的时间一定要做好评估（需要注意，该值必须在broker配置group.min.session.timeout.ms与group.max.session.timeout.ms的范围内），除了这个参数，Consumer还提供了另一个参数来控制发送心跳的频率，即：heartbeat.interval.ms，其值越小，频率就越高，通常情况下建议heartbeat.interval.ms设置为session.timeout.ms的三分之一。

除了session.timeout.ms参数超时会引起Rebalance之外，还有一个参数也有类似逻辑，即max.poll.interval.ms，这个参数就规定了，当调用poll()之后，如果在max.poll.interval.ms指定的时间内未消费完消息，也就是未再调用poll()方法，则Consumer会主动发起离开组的请求，从而产生Rebalance。

2. 分区数发生变化

这个场景也很好理解，分区数发生了变化，自然需要重新调整分区与消费者的对应关系。

3. 订阅Topic发生变化

这个场景与分区数发生变化类似，都属于常规的业务使用上的需要，没有什么好避讳的。

Rebalance全流程介绍

Kafka中Rebalance主要分为两步，第一步是JoinGroup，第二步是SyncGroup，通过Coordinator来协调各消费组的元数据信息以及组成员之间的关系，包括选举group leader、处理JoinGroup、SyncGroup请求等等。

整个Rebalance流程，主要围绕以下4种场景来处理。

场景一：新成员入组

场景二：成员主动离组

场景三：成员崩溃离组

场景四：组成员提交位移