再均衡是什么
消费组里的成员数量或订阅关系发生变化时，分区需要重新在成员之间分配，这个过程叫再均衡。它保证「一个分区同一时刻只被组内一个消费者读取」，代价是分配期间消费会短暂停顿。成员增减、订阅的 topic 变化、订阅 topic 的分区数变化都会触发；重启、发版、处理变慢被踢出组是生产环境里最常见的诱因。
基本信息
| 触发条件 | 成员加入/退出、订阅变更、分区数变化 |
|---|---|
| 直接影响 | 分区重新分配，期间消费停顿或部分分区暂停 |
| 缓解手段 | 合作式均衡、静态成员、合理调大会话与处理超时 |
| 分配策略 | Range、RoundRobin、Sticky、CooperativeSticky |
| 观测入口 | 消费组日志、group 描述、消费 lag 波动 |
降低影响的客户端配置
降低影响的客户端配置
partition.assignment.strategy=org.apache.kafka.clients.consumer.CooperativeStickyAssignor
group.instance.id=consumer-1 # 静态成员，短暂重启不触发再均衡
session.timeout.ms=45000 # 会话超时：心跳中断多久判定成员死亡
heartbeat.interval.ms=3000 # 心跳间隔，通常为会话超时的三分之一
max.poll.interval.ms=300000 # 两次 poll 的最大间隔，超时即被踢出组
max.poll.records=500 # 单次拉取条数，控制一轮处理耗时典型使用场景
- 服务发版滚动重启：用静态成员避免每个实例重启都触发一次全局再均衡
- 消费逻辑变慢导致 lag 上升：先降 max.poll.records，把单轮处理时间压回阈值内
- 扩容消费者：新实例加入必然触发再均衡，合作式策略只搬动必要分区
- 排查周期性停顿：对照再均衡日志时间点与业务延迟曲线是否吻合
- 消费组频繁抖动：检查是否有实例因健康检查失败被反复重启
关键参数读法
| 参数 | 含义 | 调错的后果 |
|---|---|---|
| session.timeout.ms | 心跳丢失多久判定成员下线 | 过小会误判离线，过大会拖慢故障转移 |
| max.poll.interval.ms | 两次 poll 的最大间隔 | 处理超时被踢出组，进入反复再均衡 |
| heartbeat.interval.ms | 心跳发送频率 | 过大会迟于会话超时才感知异常 |
| group.instance.id | 静态成员标识 | 重复设置会让新实例顶掉旧实例 |
| partition.assignment.strategy | 分区分配算法 | eager 策略会造成全量停顿 |
处理单批数据耗时超过 max.poll.interval.ms 会被踢出组，引发「处理慢→被踢→再均衡→更慢」的循环；此时调大会话超时只是掩盖症状，根因通常在单批条数或下游写入耗时。
合作式再均衡（CooperativeSticky）把一次全量停顿拆成多轮增量调整，消费几乎不停；但组内所有成员都要支持该协议，升级时需要滚动过渡，混用新旧策略会出现报错。