Rebalance 风暴排查

难度与前置

难度：进阶
前置：会看消费组状态与消费日志；知道 Rebalance 期间分区会回收。
读完能做什么：识别「风暴」与偶发再均衡，按超时/订阅抖动/最大轮询等分类止血，用 rebalance 次数与 lag 曲线验收。

适用场景

消费吞吐抖动，日志大量 Rebalance / Partition revoked
Lag 锯齿状：刚降下去又抬升
扩缩容 consumer 后长期不稳定
静态会员制 / Cooperative 分配评估

不适用：

单纯生产端流量暴增（先扩分区/下游，见积压）
Broker 整体不可用（先集群健康）
正常上线滚动发布导致的有限次数再均衡

真实场景（一条）

支付流消费组每几分钟全量 Rebalance，Lag 呈锯齿，下游 Flink 频繁空闲再追赶（见反压）。根因：单次 poll 业务处理超过 max.poll.interval.ms，被踢出组；同时另有服务每分钟重配订阅主题通配符。治理：处理移出 poll 循环 / 缩短单次批量；上调 interval 并限流；订阅改为固定主题列表。Rebalance 频率从数分钟一次降到仅发布窗口出现。

怎么做（步骤清单）

1. 确认是不是「风暴」

bash

# 消费日志关键字（示意）
grep -E "Rebalance|Revoke|Assigned|memberId" consumer.log | tail -50

# 组状态
kafka-consumer-groups.sh --bootstrap-server $BK \
  --describe --group pay-cg

信号	含义
短时间反复 Join/Leave	风暴
generation id 快速增加	风暴
Lag 锯齿与 revoke 对齐	强相关
仅发版窗口几次	通常正常

2. 根因分类树

text

Rebalance 频繁
├─ 成员进出
│  ├─ 心跳丢失 / session.timeout
│  ├─ max.poll.interval 内未再 poll（处理过重）
│  ├─ 进程 OOM / 频繁重启
│  └─ 伸缩/抢占导致实例抖
├─ 订阅变化
│  ├─ 正则订阅匹配到新主题
│  └─ 代码动态改 subscribe 列表
└─ 分配策略/新协议切换不当

3. 关键超时类参数（先理解再改）

properties

session.timeout.ms=45000
heartbeat.interval.ms=15000
max.poll.interval.ms=300000
max.poll.records=200

原则：

heartbeat.interval ≪ session.timeout
业务处理过重时：减少单次 records 或异步化处理，而不是无限加大 max.poll.interval
加大 timeout 是止血，根治是「poll 循环不被长任务堵死」

4. 代码模式：别堵死 poll

java

while (running) {
  ConsumerRecords<String, String> records = consumer.poll(Duration.ofMillis(500));
  for (ConsumerRecord<String, String> r : records) {
    // 避免此处同步打爆下游导致整批数分钟
    processFastOrEnqueue(r);
  }
  // 按需提交：与语义一致（at-least-once / 事务）
  consumer.commitAsync();
}

批量写库失败重试时，注意重试时间也吃 max.poll.interval 预算。

5. 订阅稳定化

生产尽量 显式主题列表，慎用过宽通配
变更订阅走发布，不在运行时每分钟刷新
新主题扩容有窗口，接受一次再均衡并公告

6. 与静态会员 / Cooperative 的关系

Cooperative sticky：减少「停所有分区」的停顿（版本与客户端需支持）
Static group membership：滚动发布时少抖动（运维复杂度上升）
先把踢组根因去掉，再上高级特性

7. 和 Lag 排查的分工

Lag 高且稳定：消费慢 / 扩容问题 → 积压排查
Lag 锯齿 + revoke：先停风暴，再谈扩容
分区设计不合理导致单分区热点：见分区设计

8. 观测与告警

text

告警示例：
- 5 分钟内 rebalance 次数 > N
- group generation 增长速率异常
- 消费线程重启次数

bash

echo "ts,group,generation,rebalance_cnt_5m,max_lag"

常见坑（至少牢记这些）

把 max.poll.interval 调到极大当永久方案
假死成员长期占分区，更难发现。
在 rebalance 监听里做重 IO
延长停顿，雪上加霜。
通配订阅匹配 CI 临时主题
测试主题创建即风暴。
忽略 GC / OOM 重启
表象是 rebalance，根因是内存。
提交位点与再均衡交织未处理
重复消费或丢位点；要有撤销回调里的正确提交策略。
只扩 consumer 不查踢组
实例越多，不稳定时风暴面积越大。

如何验收（可量化）

[ ] 稳态下 rebalance 仅出现在发版/扩缩容窗口
[ ] Lag 曲线不再与分钟级 revoke 锯齿共振
[ ] 故障注入（杀一个实例）恢复次数与时长符合预期
[ ] 参数变更有说明：根因 & 止血项区分
[ ] 订阅列表稳定，无运行时抖动

bash

echo "day,rebalance_cnt,p95_lag,deploy_window_rebalance"
# before,800,500000,yes
# after,12,2000,yes

sql

-- 若消费进度入仓
SELECT window_5m, SUM(rebalance_cnt) AS rb
FROM cg_metrics
WHERE dt = '${biz_date}' AND group_id = 'pay-cg'
GROUP BY window_5m
ORDER BY window_5m;

Rebalance 风暴排查 ​

适用场景 ​

真实场景（一条） ​

怎么做（步骤清单） ​

1. 确认是不是「风暴」 ​

2. 根因分类树 ​

3. 关键超时类参数（先理解再改） ​

4. 代码模式：别堵死 poll ​

5. 订阅稳定化 ​

6. 与静态会员 / Cooperative 的关系 ​

7. 和 Lag 排查的分工 ​

8. 观测与告警 ​

常见坑（至少牢记这些） ​

如何验收（可量化） ​

相关面试题 ​

Rebalance 风暴排查

适用场景

真实场景（一条）

怎么做（步骤清单）

1. 确认是不是「风暴」

2. 根因分类树

3. 关键超时类参数（先理解再改）

4. 代码模式：别堵死 poll

5. 订阅稳定化

6. 与静态会员 / Cooperative 的关系

7. 和 Lag 排查的分工

8. 观测与告警

常见坑（至少牢记这些）

如何验收（可量化）

相关面试题