Appearance
Kafka 消费组与 Rebalance：为什么会重复消费、暂停抖动、吞吐不均
Kafka 真正跑进业务里后，很多“看起来像 Kafka 不稳定”的问题，根子其实都在消费端。
最常见的现象通常是：
- Topic 消息量不大，但 lag 一直降不下来
- 扩了几个消费者实例，吞吐没涨，反而更抖
- 某些实例很忙，某些实例几乎空闲
- 发布或重启后，大量消息重复执行
- 业务方说“消费偶尔会停一下，然后又恢复”
这些现象背后，往往都离不开下面几个关键词：
- 消费组
- 分区分配
- offset 提交
- rebalance
直接相关。
先说结论
Kafka 消费端要先抓住 4 件事：
- 分区数决定消费并行上限
- offset 提交决定重复与丢失边界
- rebalance 会带来短暂消费抖动
- 消费耗时过长或心跳异常，很容易触发频繁重平衡
真正线上最容易踩坑的，不是“不会用 Consumer Group”，而是把它想得太简单：以为多开几个实例就一定更快，以为 rebalance 只是轻量切换，以为 offset 提交只是个小配置。
一、Consumer Group 真正解决的是什么
消费组可以先理解成：
- 一组共同消费同一份 Topic 数据的消费者实例
它解决的核心问题有两个：
- 同组内分摊分区
- 组间彼此独立消费
这意味着：
- 同一个消费组是在“协作处理同一批消息”
- 不同消费组是在“各自拿到完整的一份消息流”
这个边界一旦没想清楚，就容易在架构上犯错。比如有些业务明明只是需要多实例并行处理，却误拆成多个消费组，结果把一份消息重复消费了多次。
二、为什么分区数决定并行上限
Kafka 一个很关键的限制是：
- 同一消费组内，一个分区同一时刻通常只会分配给一个消费者实例
所以：
- 3 个分区的 Topic，在同一消费组下，最多只能有 3 个消费者真正干活
所以消费者扩容前一定要先问一句：
- 是消费者数量不够，还是分区数量本来就限制了并行度
很多线上“扩容无效”的根因就在这里。不是实例不够，而是上限早就被分区数卡死了。
三、Rebalance 是什么
当消费组成员变化或分区分配发生调整时，Kafka 会触发重新分配分区。
常见触发原因：
- 消费者启动或下线
- 心跳超时
- Topic 分区变化
这就是 rebalance。它不是异常，而是 Kafka 为了维持消费组协同工作的正常机制。
但它虽然正常，不代表它没有代价。
四、为什么 Rebalance 会让业务感觉“卡一下”
因为在重平衡期间：
- 分区归属要重新计算
- 某些消费者会暂时停止原有消费
如果 rebalance 过于频繁，业务侧就会明显感到：
- 消费抖动
- 吞吐下降
- 延迟上升
更糟一点时，还会触发一连串连锁反应：
- 批量消费任务中断重来
- offset 未及时提交导致重复消费放大
- 某些分区来回漂移，热点分区一直分不到稳定实例
所以从工程角度看，rebalance 虽然是正常机制，但它绝不是“可以随便频繁发生的小波动”。
五、哪些情况会导致频繁 Rebalance
1. 消费逻辑太慢
如果一次处理耗时过长，消费者长时间不能正常 poll，就可能被协调器认为“它卡住了”。
2. 批量拉太多，单次处理时间过长
比如一次拉了很多消息，但业务线程处理很慢，结果一个批次消化时间远超心跳和会话窗口，也容易诱发 rebalance。
3. 消费者实例不稳定
频繁重启、容器抖动、网络波动都会放大 rebalance 次数。
4. 发布策略不合理
如果线上在扩容、滚动发布、节点迁移时没有控制节奏，一次性让大量实例上下线，也会触发明显的消费抖动。
5. 分区变更后没有评估影响
增加 Topic 分区本身也可能触发新的分配过程。如果业务在高峰期临时改分区，往往会把消费链路一起带抖。
六、Offset 提交为什么特别关键
很多重复消费问题，本质都不是 Kafka 出错，而是 offset 提交边界和业务成功边界没有对齐。
如果提交过早
业务还没真正落库、发券、更新状态，offset 已经推进。
一旦后续步骤失败，你会发现 Kafka 侧看起来“已经消费了”，业务侧却没有真正成功，这就是最典型的丢失感知风险。
如果提交过晚
消费者在业务已经成功后还没来得及提交 offset 就宕机，重启后又会把这批消息重新拉出来。
所以 offset 提交从来没有“绝对完美”。它本质上是在：
- 重复消费
- 丢失风险
之间做边界控制。
真正稳妥的思路通常是：
- 把业务处理设计成幂等
- 再让 offset 提交尽可能贴近业务成功点
这样就算 rebalance、重启、网络抖动发生，系统也不会被一次重复消费轻易击穿。
七、吞吐不均为什么经常发生
常见原因有三类：
- key 分布不均导致热点分区
- 某些分区消息量远高于其他分区
- 某个消费者处理逻辑更慢
这时你会看到：
- 某些实例很忙
- 某些实例很闲
根因不一定在消费组机制本身，而可能在上游分区策略和业务模型上。
最典型的就是：
- 以用户 ID、商户 ID、订单号做 key，但某些头部用户或大商户天然更热
- 少数分区承担了绝大多数流量
- 你以为是在“扩容消费者”，实际是在“让更多空闲实例围观热点分区”
这种场景下，继续加消费者意义很有限，更应该回头看：
- 分区 key 设计是否合理
- 是否需要拆热点
- 是否需要把重任务异步化
- 是否需要单独隔离高耗时消息
八、消费端更实用的治理思路
1. 分区数和消费并行设计一起考虑
分区不是后面随便补的“运维参数”，它本质上决定了后续消费并发上限。
2. 消费逻辑尽量快进快出
消费线程最好只做必要校验、幂等判断和轻量处理，重操作尽量异步化或拆到后置链路。
3. offset 提交和业务成功边界保持一致
不要只图“提交快”，也不要完全忽略重复消费成本。
4. 对重复消费预留幂等能力
这是最现实的一层保险。
5. 把 rebalance 当成要被治理的波动源
包括：
- 合理设置心跳与会话参数
- 控制单批次处理时长
- 发布时采用平滑滚动策略
- 对消费者实例异常重启做告警
九、线上排查消费抖动时的顺序
遇到“消费者一会儿快、一会儿停”的问题，可以优先按这个顺序看：
- 看消费组是否在频繁 rebalance。
- 看实例是否有重启、GC 停顿、线程池阻塞或网络抖动。
- 看单次消息处理时间是否过长，是否超过配置窗口。
- 看 offset 提交是否滞后，是否存在批量重复消费。
- 看分区是否严重倾斜，热点是否集中在少量分区。
- 最后再考虑是否需要扩容实例或调整分区。
很多团队一上来就扩容，其实问题不在“消费能力不够”，而在“消费协作机制已经不稳定”。
一句话总结
Kafka 消费端真正难的，不是把消息拉下来，而是把消费组、分区、offset 和 rebalance 这几层协同稳定地跑起来。
当你把并行度上限、提交边界、热点倾斜和重平衡成本想清楚之后，很多“莫名其妙的重复消费、暂停抖动、吞吐不均”都会从玄学问题变成可定位、可治理的工程问题。