Skip to main content

消费者 Rebalance 原因与排查

频繁 Rebalance 通常由消费者侧异常引起，常见原因有三类。

常见原因​

1. 处理过慢（最常见）​

消费者进程仍在运行，但单次 poll() 与业务处理耗时超过 max.poll.interval.ms（默认 5 分钟）。Coordinator 判定该成员失效，将其踢出组并触发 Rebalance。

典型表现：消费 Lag 上升，与 Rebalance 频率同步升高。

处理方向：优化业务耗时与 GC；或适当调大 max.poll.interval.ms；减小 max.poll.records 以降低单次处理量。

2. 心跳超时​

网络抖动、Full GC（Stop The World）等导致心跳无法在 session.timeout.ms（默认 45 秒）内送达，成员被判定离线。

注意：本地 Debug 断点暂停过久，也容易触发此类超时。

处理方向：排查网络与 JVM 停顿；合理设置 session.timeout.ms 与 heartbeat.interval.ms（后者通常约为前者的 1/3）。

3. 频繁加入 / 离开​

上线、滚动重启或实例数波动时，成员反复进出消费组。若多个实例启动时间交错，可能在上一轮 Rebalance 尚未完成时再次触发，形成惊群效应，组内长期处于不稳定状态。

处理方向：控制发布节奏；使用静态成员（group.instance.id）；避免短时间内反复扩缩容。

关键参数​

参数默认值作用
session.timeout.ms45000心跳超时阈值，超时则踢出成员
heartbeat.interval.ms3000心跳发送间隔，须小于 session.timeout.ms
max.poll.interval.ms300000两次 poll() 之间的最大间隔
max.poll.records500单次 poll() 拉取条数上限

约束关系：heartbeat.interval.ms < session.timeout.ms < max.poll.interval.ms。max.poll.records 过大时，单次批处理时间容易逼近 max.poll.interval.ms。

排查步骤​

  1. 查日志：确认是否出现 REBALANCE_IN_PROGRESS 及成员被踢出的具体原因（心跳超时 / poll 超时）。
  2. 看监控：Lag 与 Rebalance 同时飙升，优先怀疑处理过慢。
  3. 核配置：检查 max.poll.records、超时类参数是否与业务耗时匹配。

本地复现​

将 max.poll.records 设为较大值（如 1000），并在消费逻辑中人为延迟处理，可在控制台观察到因 max.poll.interval.ms 触发的 Rebalance 日志，用于验证参数行为。