消费组 Rebalance 机制：从触发到完成的完整拆解
Rebalance，说白了就是消费组成员发生变动时，Kafka 重新分配分区归属的过程。我刚开始接触 Kafka 时，觉得 Rebalance 就是个「重新分一下」而已，直到线上有一次频繁 Rebalance 导致消费延迟飙升……嗯，从那以后我再也不敢小看它了。
这一节，咱们把 Rebalance 的触发条件、完整流程、两种策略掰开揉碎讲清楚。
Rebalance 触发条件：什么时候会触发？
触发 Rebalance 的场景其实就几类，我列个表给你看：
| 触发场景 | 具体表现 | 我遇到的坑 |
|---|---|---|
| 消费者加入 | 新消费者启动并加入消费组 | 新实例启动时，如果 session.timeout.ms 设置太短，容易触发不必要的 Rebalance |
| 消费者离开 | 消费者主动关闭或崩溃 | 我曾经遇到过消费者进程被 OOM killer 杀掉，导致组内频繁 Rebalance |
| 消费者超时 | 心跳超时，GroupCoordinator 认为消费者已死 | GC 停顿过长导致心跳丢失，这个坑我踩过不止一次 |
| 分区数变化 | Topic 新增或减少分区 | 运维扩分区时，如果没控制好节奏，整个组会全部 Rebalance |
| 订阅 Topic 变更 | 消费者修改了订阅的 Topic 列表 | 代码中动态修改 subscribe() 时要注意，会触发 Rebalance |
注意：心跳超时是最常见的「隐形杀手」。很多团队把 session.timeout.ms 设成 30 秒，但 GC 停顿一次可能就 40 秒，消费者直接被踢出组。我个人习惯把 session.timeout.ms 设到 45 秒以上，配合 max.poll.interval.ms 一起调。
Rebalance 的完整流程：到底发生了什么？
Rebalance 不是瞬间完成的，它分几个阶段。我画了一张流程图，帮你理解整个过程：
流程看起来不复杂，但每个阶段都有细节。我重点说几个容易出问题的地方：
- 停止消费阶段：消费者会先提交当前偏移量，再停止拉取。如果提交失败，重启后可能重复消费。
- 选举 Leader：Leader 不是固定的，谁先加入谁当 Leader。Leader 负责算分配方案，算完就广播出去。
- 同步分配结果：所有消费者收到新分配后，开始从新分区拉取数据。这里有个细节——消费者会先重置偏移量，再开始消费。
我的经验：Rebalance 期间，消费是完全暂停的。如果你的业务对延迟敏感，建议把 Rebalance 耗时控制在 5 秒以内。我一般通过监控 rebalance-lag 指标来预警，一旦超过 10 秒就报警。
Rebalance 的两种策略：Eager vs Cooperative
Kafka 支持两种 Rebalance 策略，它们的核心区别在于「停不停所有消费者」。
| 对比维度 | Eager Rebalance（急切策略） | Cooperative Rebalance（协作策略） |
|---|---|---|
| 停止范围 | 所有消费者全部停止 | 只停止受影响的分区 |
| 暂停时间 | 整个 Rebalance 期间 | 分阶段暂停，时间更短 |
| 分区移交 | 先撤销所有分区，再重新分配 | 逐步撤销和分配，分多轮完成 |
| 适用场景 | 分区数少、消费者少 | 分区数多、消费者多、对延迟敏感 |
| Kafka 版本 | 所有版本都支持 | 2.4+ 开始支持 |
Eager Rebalance：简单粗暴
Eager 策略的逻辑很简单——先全部停掉，再重新分配。你想想看，如果消费组有 100 个消费者、每个消费者负责 1000 个分区，那 Rebalance 一次，所有分区都要重新分配。这个过程就像把一堆积木全部推倒，再重新搭起来。
我早期用 Eager 策略时，遇到过一个问题：某个消费者负责的分区特别多，Rebalance 时它提交偏移量花了很长时间，导致整个组都在等它。后来我查了日志，发现是那个消费者的网络带宽被打满了。
Eager 的优缺点：
- 优点：实现简单，逻辑清晰，适合小规模场景
- 缺点：暂停时间长，分区越多影响越大
Cooperative Rebalance：渐进式优化
Cooperative 策略是 Kafka 2.4 引入的改进方案。它的核心思想是「只动需要动的部分」。举个例子：
- 如果只是新增一个消费者，Cooperative 只会把部分分区从老消费者手上移交到新消费者，其他消费者完全不受影响
- 如果某个消费者崩溃了，Cooperative 只会把它的分区重新分配给其他消费者，不会影响其他消费者的现有分区
说白了，Cooperative 把一次大 Rebalance 拆成了多轮小 Rebalance。每一轮只处理一部分分区的移交，直到所有分区都稳定下来。
我建议：如果你的 Kafka 版本是 2.4 以上，优先使用 Cooperative 策略。配置方式很简单，在消费者端设置：
partition.assignment.strategy=org.apache.kafka.clients.consumer.CooperativeStickyAssignor两种策略的对比总结
我再用一个表格帮你快速对比：
| 场景 | Eager 表现 | Cooperative 表现 |
|---|---|---|
| 新增 1 个消费者 | 全部暂停，重新分配所有分区 | 只移交部分分区，其他消费者继续消费 |
| 1 个消费者崩溃 | 全部暂停，重新分配所有分区 | 只重新分配崩溃消费者的分区 |
| 新增 10 个分区 | 全部暂停，重新分配所有分区 | 分多轮移交，每轮只处理部分分区 |
| 100 个消费者同时重启 | 全部暂停，一次性重新分配 | 分多轮逐步恢复，每轮只处理部分消费者 |
注意：Cooperative 策略虽然好，但不是万能的。如果你的消费者数量很少（比如 2-3 个），Eager 策略的暂停时间也就几秒钟，没必要换成 Cooperative。我见过有人为了「用新特性」强行切换，结果因为版本兼容问题出了故障。嗯，技术选型还是要看实际场景。