Kafka 消费者组 rebalancing 风暴：一次 200 万重复消息事故的根因与治理

一、现象与背景

去年 Q4，我们的支付对账系统开始报「重复记账」。对账服务以 Kafka 消费组形式消费 pay-notify topic，该 topic 有 32 个分区，消费组 12 个实例，日均消息量约 4200 万条。某天早高峰一个 10 分钟窗口内，对账库多出了约 200 万条重复记录，客服工单直接爆量。更糟的是：监控里 consumer lag 一度飙到 180 万，随后又瞬间清零——这种「忽高忽清零」的抖动持续了 40 多分钟，期间消费组反复 rebalance。

二、原理与根因

Kafka 的「至少一次」语义建立在 offset 提交与分区分配解耦之上：分区分配由 GroupCoordinator 按 rebalance 协议维护（我们当时用的是 classic，即 Eager 协议），offset 由消费者自己 commitSync 提交。根因出在三个参数的相互掣肘：

• max.poll.interval.ms（默认 300000，我们设成了 60000）：两次 poll 的最大间隔，超了 broker 就认为你失联，踢出组并触发 rebalance；
• session.timeout.ms（默认 45000，我们设成 15000）：心跳超时；
• heartbeat.interval.ms（默认 3000，我们设成 5000）。

我们的消费逻辑里，每条消息要调用下游对账 API，P99 耗时 400ms 且带 3 次重试；max.poll.records 当时是 500。于是单批 500 条里只要命中几条下游慢调用 + 重试，整批处理耗时就能冲破 60s 的 max.poll.interval.ms，被 broker 判定失联并踢出 → 触发 rebalance → 分区重新分配 → 其他实例接管但旧 offset 还没提交 → 重复消费。这就是典型的「rebalance 风暴」：一个实例被踢，全体重排；重排过程中又有实例正在跑慢批，再次被踢，循环往复。Eager 协议每次都把全组分区的归属重排一遍，进一步放大了抖动面。

三、具体做法

1. 把批次拆小、把间隔放大，二者必须联动调：

max.poll.records     = 100        # 从 500 降到 100
max.poll.interval.ms = 120000     # 给足单批处理时间
session.timeout.ms   = 30000      # 保持约 3x heartbeat
heartbeat.interval.ms= 3000

2. 把「下游调用」从 poll 主循环里挪出去：poll 只负责拉消息，交给线程池异步处理，poll 循环本身保持 <1s 返回，从而彻底和 max.poll.interval.ms 解耦。
3. 消费端幂等：对账库用 biz_id + seq 做唯一键，INSERT ... ON DUPLICATE KEY UPDATE 兜底，即便重复投递也不产生脏数据。
4. 协议迁移：Kafka 2.4+ 开 group.protocol=coop（KIP-429 协同再均衡），rebalance 只迁移受影响的分区，抖动面从「全组」降到「个别分区」。

四、踩过的坑与反直觉之处

• 反直觉 1：以为「调大 max.poll.interval.ms 就行」，结果单批还是 500 条，慢批照样超时——这个参数是「给时间」，不是「让你干更多活」，必须和 max.poll.records 联动。
• 坑 2：commitAsync 不检查错误，rebalance 时正在飞的 offset 提交会静默丢失，导致重复；改用 commitSync 或带回调校验。
• 坑 3：曾把 session.timeout.ms 调得比 max.poll.interval.ms 还小，心跳还没到就超时，rebalance 反而更频繁。
• 坑 4：监控只看 consumer lag，看不到「rebalance 次数」；加上 consumer-rebalance-total 指标后才发现，那 40 分钟里 rebalance 了 23 次。

五、结论与可复用清单

• rebalance 风暴的根因几乎都是「单批处理时间 > max.poll.interval.ms」，治理核心是把 poll 循环变轻、把慢 IO 移出主循环。
• 参数联动调，别单点改：max.poll.records ↓、max.poll.interval.ms ↑、session.timeout ≈ 3× heartbeat。
• 消费端必须幂等，「至少一次」语义下幂等是唯一可靠兜底。
• 能升级到协同再均衡（KIP-429）就升，抖动面显著缩小。
• 监控要加 rebalance 次数与耗时，只看 lag 会漏掉「抖动型」故障。

想抛一个开放问题：在 Flink / 自研流引擎里，checkpoint 与 offset 提交的一致性你们是怎么对齐的？我猜不少人其实没认真处理过「offset 提交成功但下游没落地」这一类撕裂窗口，欢迎交流。