Kafka 消费组与再平衡深入：协议演进、分配策略与稳定性调优

「又再平衡了」是 Kafka 消费者最大的痛点：一触发，整个消费组秒级停顿，吞吐断崖。本文不讲消费组怎么用，而是深入再平衡的协议与机制——为什么会发生、如何发生的、怎样让它少发生，以及发生了如何快速恢复。

1. 消费组模型与再平衡的本质

1.1 消费组基本模型

一个消费组由若干消费者实例组成，组内的每个分区被恰好一个消费者持有。组的目标状态是「每个消费者分到的分区负载尽量均衡」。

# 消费组的核心状态
# 组坐标: groupId + memberId（实例注册身份）
# 组状态: Empty / PreparingRebalance / CompletingRebalance / Stable
# 组协调者: 某个 broker 担任，负责管理成员与分配

**再平衡（Rebalance）**是消费组在成员变化、分区变化或订阅变化时，重新分配分区的过程。它不可避免，但高频发生就是事故。再平衡的本质代价：期间组内消费暂停、已拉取未提交的位移失效、消费者需要重新定位。

1.2 再平衡的触发源

触发再平衡的四大来源：

• 成员加入/离开：新消费者启动、旧消费者崩溃或主动关闭。
• 心跳超时：消费者心跳断了，协调者判定下线，触发重新分配。
• 分区数变化：主题扩容分区（扩容 partition）触发全组重分配。
• 订阅变化：消费者动态订阅（subscribe 的 pattern）变化。

其中「心跳超时」和「处理耗时过长」是生产中最常见的误触发，也是稳定性调优的主战场。

2. 两代再平衡协议：Eager 与 CooperativeSticky

2.1 Eager 再平衡（旧协议）

Kafka 早期的再平衡是全量（Eager）的：任何一个成员变动，协调者让所有成员交回分区，全部停止消费，然后重新分配全部分区。

# Eager 再平衡的代价
# 1) 所有消费者 revoked（交回所有分区）
# 2) 消费全部暂停（revoke timeout 内必须完成）
# 3) 重新 JoinGroup 并等待分配完成
# 4) 全组恢复消费 —— 分区越多、成员越多，停顿越久

Eager 的优点是实现简单，缺点是放大问题：一个消费者抖动，全组陪绑。消费者数量与分区数量越大，Eager 的停顿越不可接受。

2.2 CooperativeSticky 增量再平衡

Kafka 2.4+ 引入 CooperativeSticky：只让「受影响的分区」重新分配，未受影响的分区继续由原消费者持有，消费不中断。

# CooperativeSticky 的关键机制
# 1) 只 revoke 需要挪动的分区（增量式，非全量）
# 2) 保持尽可能多的分区不动（sticky：尽量维持既有分配）
# 3) 多轮收敛：每次只挪一部分，逐步达到均衡
# 4) 消费组整体不停顿，只有被挪动分区的消费者短暂暂停

CooperativeSticky 对动态扩缩容、滚动重启的友好度远超 Eager：扩容消费者时，旧分区不挪动，只有新分区分配给新成员；成员退出时只迁移它名下的分区。现代版本（Kafka 2.4+）默认即为 CooperativeSticky，除非显式指定 assignor 否则优先使用。

3. 再平衡的完整流程

3.1 JoinGroup / SyncGroup / Heartbeat

一次再平衡由协调者与消费者之间的三类 RPC 完成：

# 再平衡流程（协议层）
# 1) 触发: 成员变动/心跳超时 → 协调者进入 PreparingRebalance
# 2) JoinGroup: 各消费者发送加入请求，携带订阅信息
#    → 协调者选定 leader 消费者，leader 负责计算分区分配
# 3) SyncGroup: leader 将分配结果发给协调者，协调者广播给所有成员
# 4) Heartbeat: 成员以 heartbeat.interval.ms 周期上报，维持成员资格
# 5) 状态迁移: PreparingRebalance → CompletingRebalance → Stable

关键参数：

• heartbeat.interval.ms（默认 3s）：心跳间隔，越小越快发现下线，但网络开销大。
• session.timeout.ms（默认 45s）：协调者判定成员「已死」的超时窗口。心跳在窗口内没到，成员被踢出。
• max.poll.interval.ms（默认 300s）：两次 poll 的最大间隔。超过说明消费者处理太慢，协调者强制将分区 revoke 出去。
• group.initial.rebalance.delay.ms（默认 3s）：协调者等待成员加入的宽限，让同一批变动合并成一次再平衡。

3.2 再平衡的两次典型停滞点

停顿发生在两个时刻：revoke 阶段（交回分区）与join 阶段（等待组内所有成员到齐）。消费组越大、成员越多、成员分布越广，join 等待越长。这也是「全组秒级停顿」的直接来源。

4. 分区分配策略对比

4.1 四种 Assignor 的取舍

# 显式指定分配策略
props.put(ConsumerConfig.PARTITION_ASSIGNMENT_STRATEGY_CONFIG,
          CooperativeStickyAssignor.class.getName());

工程建议：无脑用 CooperativeSticky。它同时解决「均衡」与「停顿」两个诉求，是 2.4+ 的默认选择；只有在强依赖「同主题消费者连接复用」等老特性时才考虑 Range/RoundRobin。

5. 再平衡频繁的根因与排查

5.1 两类最常见的误触发

心跳超时（session.timeout 内没收到心跳）与 poll 超时（max.poll.interval 内没 poll）是生产再平衡的头号来源，二者背后的根因通常是同一件事：消费者处理耗时过长——比如下游调用慢、批量处理大、单条消息处理有阻塞。

# 排查再平衡频繁的路径
# 1) 看协调者日志: 找 JoinGroup/SyncGroup 次数，确认触发类型
# 2) 看消费者日志: 找 "Join group failed" / "member has been kicked"
# 3) 看处理耗时: 单个 poll 循环耗时是否接近 max.poll.interval
# 4) 看 GC/阻塞: 是否频繁 Full GC、外部 API 慢调用拖住线程

5.2 调优参数组合

按「先消根因、再调参数」的顺序：

• 根因优先：缩短单次 poll 的批大小、把慢调用改成异步/超时、控制 Full GC 频率。参数只是兜底，不能替代修根因。
• 如果确实是处理慢但业务需要：调大 max.poll.interval.ms 与 max.poll.records 配合（一次少拉、多轮处理），避免处理超时。
• 心跳与前向健康：调小 heartbeat.interval.ms（如 1~2s）+ 适度调大 session.timeout.ms（如 60s），让「心跳慢」与「处理慢」解耦——新版本心跳由独立线程发送，不在 poll 线程内阻塞。

6. 稳定消费组的工程实践

6.1 静态成员：让实例「名分固定」

静态成员（Static Membership）：给消费者配 group.instance.id，使实例身份不随进程重启变化。这样实例重启时不发生再平衡，分区由新进程接管继续消费，位移也不用重新分配。

props.put(ConsumerConfig.GROUP_INSTANCE_ID_CONFIG, "consumer-host-1");

静态成员适合有状态消费者（如带本地缓存、需要维持分区与节点的稳定绑定）。代价是协调者会为静态成员保留较长时间（session.timeout 更大），下线检测变慢。

6.2 滚动重启与扩容

• 滚动重启：停一个消费者 → 它被判定下线 → 触发增量再平衡（CooperativeSticky 只挪它的分区）→ 重启加入 → 拿回分区。全程其他消费者不停顿。
• 扩容：新消费者加入，CooperativeSticky 只把「新分区或超载分区」匀给它，旧分配尽量不动。扩容后等 1~2 轮再平衡收敛即可。
• 监控：盯 RebalanceRate（每消费者每秒再平衡次数）与 JoinGroup 次数，超过阈值告警。

6.3 位移提交与再平衡配合

再平衡发生时，被 revoke 分区的消费者可能有「已 poll 未提交」的位移。优雅退出（commitSync 收尾）能减少重复消费；但任何消费端重复不可避免，必须配合消费幂等（唯一键去重）。再平衡只能减少重复窗口，消灭重复要靠消费端。

7. 常见坑清单

• 分区数不是越大越好：分区数远大于消费者数时，再平衡开销与位移管理成本上升；扩容分区前确认消费端能跟上。
• 多主题共享消费组：成员订阅不同的主题集合时，Range 分配会失衡——优先保证订阅一致。
• 版本差异：消费者与协调者版本不一致，CooperativeSticky 可能回退到兼容协议，检查 broker 与客户端版本。
• 心跳线程被阻塞：若旧版本心跳在 poll 线程内发送，慢处理会连带心跳超时——升级客户端让心跳独立线程化。

8. 总结

消费组再平衡的工程本质是「用协议与参数把停顿压到最小」：协议上选 CooperativeSticky 增量再平衡，机制上理解 JoinGroup/SyncGroup 流程与参数，根因上优先修处理耗时而非盲目调参，结构上用静态成员与优雅退出稳定实例。记住：再平衡不会消失，目标是从「全组秒级停顿、一天 N 次」降到「局部毫秒级、一天 0~1 次」。稳定性是设计出来的，不是参数堆出来的。