Kafka 消费组再平衡（Rebalance）是很多线上消费延迟突发飙升的”隐形元凶”。当消费者心跳超时、单次 poll 处理过久或频繁上下线时，消费组会触发全局再平衡，所有分区被回收并重新分配，期间消费完全暂停——这就是所谓的”再平衡风暴”。本文结合一次生产排障复盘，拆解再平衡的根因、排查手段与可落地的配置方案。
一、现象：消费延迟突然飙升，吞吐量断崖
再平衡风暴最典型的表现是：监控面板上消费滞后（lag）毫无征兆地暴涨，但消费者进程的 CPU、内存、网络都”看似正常”。打开消费者日志，会成片出现 Revoking partitions、Partitions reassigned、(Re-)joining group 之类信息。更棘手的是，这种停顿可能从几百毫秒到几十秒不等，且呈阵发性——压测或发布时才暴露，平时难复现。
二、再平衡到底是什么
Kafka 的 Group Coordinator 负责维护消费组成员关系，并在成员变动、订阅变更或心跳失联时把分区重新分配给存活的消费者，这个过程就是再平衡。问题在于：再平衡期间所有分区会被短暂”冻结”，消费者必须放弃当前分区、重新加入组、等待新分配生效，整组消费随之停摆。
1. Eager 与 Cooperative-Sticky 两种协议
旧版默认的 Eager 协议采用”先全部撤销、再统一分配”的策略（stop-the-world），分区越多停顿越长；新版 Cooperative-Sticky 协议支持增量再平衡，只迁移真正需要挪动的分区，大幅缩短停顿。下面的消费者配置同时收紧了心跳与会话超时，并切换到增量再平衡：
Properties props = new Properties();
props.put("bootstrap.servers", "broker1:9092,broker2:9092");
props.put("group.id", "order-consumer");
// 增量再平衡，减少 stop-the-world 停顿
props.put("partition.assignment.strategy",
"org.apache.kafka.clients.consumer.CooperativeStickyAssignor");
props.put("session.timeout.ms", "45000"); // 心跳会话超时
props.put("heartbeat.interval.ms", "15000"); // 心跳间隔，建议 ≤ 1/3 session
props.put("max.poll.interval.ms", "300000"); // 两次 poll 最大间隔
props.put("max.poll.records", "100"); // 单次拉取条数，处理快
props.put("enable.auto.commit", "false"); // 手动提交，避免位移丢失三、再平衡风暴的五大根因
绝大多数风暴都能归到下面五类。定位时建议按顺序排查：
- GC 停顿导致心跳线程被阻塞：Full GC 或长时间 STW 让心跳线程无法在
session.timeout.ms内发心跳，Coordinator 判定消费者”死亡”并将其踢出，触发再平衡。 - 单次 poll 处理过久：业务逻辑在 poll 返回的批次上同步做了重计算或外部 IO，处理时间超过
max.poll.interval.ms，Coordinator 同样认为消费者失联。 - 消费者频繁上下线：滚动发布、Pod 重启、OOM 自愈如果没有”静态成员”保护，每一次上下线都是一次全组再平衡。
- 分区数过多：单组几千个分区时，分配计算与状态同步本身就很慢，再平衡窗口被拉长。
- 消费逻辑同步阻塞：在消费主线程里调用外部 HTTP、抢数据库锁、写慢存储，直接拉大 poll 间隔，与上述第二类叠加。
| 根因 | 触发条件 | 典型日志线索 | 解决方向 |
|---|---|---|---|
| GC 停顿 | STW 超过 heartbeat 阈值 | 日志出现长时间无心跳 + GC 日志 | 降堆压力、换 G1/ZGC、解绑心跳线程 |
| poll 超时 | 单批处理 > max.poll.interval | Commit failed / Member left group | 减小 max.poll.records、异步化 |
| 频繁上下线 | 发布/重启无静态成员 | 反复 Joining group | 开启 group.instance.id |
| 分区过多 | 单组数千分区 | 再平衡耗时长 | 拆分消费组、减少分区 |
| 同步阻塞 | 主线程外调 IO | 处理耗时曲线尖刺 | 线程池异步、快速 poll |
四、如何确认再平衡正在发生
最直接的是用命令行观察消费组状态与分区分配。如果 STATE 在 Stable 与 PreparingRebalance 之间反复横跳，几乎可以断定风暴存在：
bin/kafka-consumer-groups.sh \
--bootstrap-server localhost:9092 \
--describe --group order-consumer
# 关注列：STATE、LAG、PARTITION、CLIENT-ID
# 配合日志中的 rebalance 关键字统计频率更体系化的做法是采集 JMX 指标并在 Grafana 看板告警，核心是 kafka.consumer:type=consumer-coordinator-metrics 下的 rebalance-total 与 partition-revoked-total。一旦每分钟再平衡次数超过个位数，就该介入。配合 Prometheus JMX Exporter 暴露即可：
# jmx_exporter 规则片段（节选）
- pattern: kafka.consumer<type=consumer-coordinator-metrics, client-id=(.*)>\w*\.?rebalance-total
name: kafka_consumer_rebalance_total
- pattern: kafka.consumer<type=consumer-coordinator-metrics, client-id=(.*)>\w*\.?partition-revoked-total
name: kafka_consumer_partition_revoked_total五、解决：从”止血”到”根治”
止血靠调参，根治靠架构。推荐按以下顺序落地：
- 把
heartbeat.interval.ms设为session.timeout.ms的 1/3 以内，给心跳留出余量。 - 调大
max.poll.interval.ms，并减小max.poll.records让单批处理更快返回。 - 切换到
CooperativeStickyAssignor，把全量再平衡变成增量再平衡。 - 给每个消费者实例配置唯一
group.instance.id，滚动发布不再触发整组再平衡（静态成员）。 - 消费主线程只做”拉取 + 入队 + 提交”，重 IO 与计算下沉到线程池，避免阻塞 poll。
- 对再平衡次数设监控告警，把问题消灭在苗头期。
六、实战复盘：一次订单消费卡顿
某次大促压测中，订单消费组 lag 从 0 一路飙到 200 万。初步排查发现：消费者 JVM 存在 3–5 秒的 GC 停顿，心跳线程偶发被 STW 堵住，超过心跳阈值被踢；同时 max.poll.records=500 导致单批处理耗时 8 秒，逼近 max.poll.interval.ms 上限。两者叠加，再平衡每小时触发 60+ 次，整组几乎一直在”重新分配”而非消费。
我们的动作清单：① 将 max.poll.records 降到 100；② max.poll.interval.ms 提到 600000；③ 切换 CooperativeStickyAssignor；④ 给消费者加 group.instance.id=order-1..N 启用静态成员；⑤ 把支付回调等同步 IO 改为线程池异步。结果：再平衡次数从每小时 60+ 降到 0，lag 在 30 分钟内回零，消费吞吐恢复平稳。
七、配置速查表
| 参数 | 默认 | 建议值 | 说明 |
|---|---|---|---|
| partition.assignment.strategy | RangeAssignor | CooperativeStickyAssignor | 增量再平衡，缩短停顿 |
| session.timeout.ms | 45000 | 45000 | 心跳会话超时，别调太小 |
| heartbeat.interval.ms | 3000 | 15000 | ≤ 1/3 session |
| max.poll.interval.ms | 300000 | 300000–600000 | 单批处理上限 |
| max.poll.records | 500 | 100–200 | 单批少拿，处理快 |
| group.instance.id | 无 | 唯一实例 ID | 静态成员，免发布再平衡 |
九、几个常见误区
最后提醒几个高频误区，避免”改了参数却没用”：
- 盲目调小 session.timeout.ms：有人为了”更快踢出死节点”把它设到 5 秒，结果正常 GC 抖动就被误判死亡，反而加剧风暴。心跳超时宜宽松，处理超时靠 max.poll.interval 兜底。
- 只降 max.poll.records 却不异步化：单批小了但单条处理仍慢，总耗时没降，再平衡依旧。根因是主线程阻塞，必须异步下沉。
- 开了静态成员却忘了唯一 ID：group.instance.id 必须每个实例不同，若重复赋值，Coordinator 会把后上线的实例踢掉，适得其反。
- 忽略监控只看日志：再平衡是阵发性问题，靠日志事后翻很难定位。rebalance-total 指标 + 告警才是正道。
八、结语
再平衡不是洪水猛兽，关键是别让它”风暴化”。把心跳与处理解耦、用增量再平衡、开静态成员，基本能根治绝大多数消费组卡顿。更系统的 Kafka 排障思路可参考《Kafka 消息积压与重复消费排查》，入门可靠消息模型见《Kafka 可靠消息入门》；若想评估 Kafka 兼容的轻量替代，可看《Redpanda 实战：Kafka 兼容流处理》。把监控做在前面，再平衡就只是一次平滑的调度，而不是一场事故。
