1. 半夜的连环告警：积压、重复、丢数据，全指向了同一个“惯犯”
半夜两点被电话叫醒，线上 Kafka 消费延迟从几百条飙到几十万条，重启消费者之后更离谱——同一个订单被处理了三次，还有几个订单在日志里彻底没了下文。第一反应是 Broker 出问题了？是生产者重试把消息搞乱了？一通排查下来，CPU、磁盘、网络全部正常，最后翻消费组日志才看到那行熟悉的字：Preparing to rebalance group。
这篇文章我不是想讲某个具体的 Kafka 参数怎么配，而是想给所有被积压、重复、丢失折磨过的同学一个统一的排查思路。这三类问题看着症状各不相同，但在绝大多数生产环境下，它们的根源都是同一个——消费组 Rebalance。你把 Rebalance 的触发机制、它对消费进度的影响、以及它与 offset 提交之间的时间关系理清楚，就能从“头痛医头脚痛医脚”变成一次性解决一串问题。
本文适合谁看？正在被线上消息乱象困扰的后端开发、中间件运维同学，以及准备深入理解消费端机制、想绕开经典坑的新手。看完之后，你再遇到类似告警，至少知道第一眼该翻哪个日志、点开哪块监控，而不是在几个面板之间反复横跳。
1.1 那晚发生了什么
先说场景。某个订单消息的消费组原本很稳定，lag 一直贴着零。那天晚上突然有人发版，重启了一批消费者实例，紧接着 lag 开始爬升。于是有人又重启了一次，想着“重启治百病”，结果这次重启非但没恢复，反而触发了新一轮重平衡，lag 直接冲上了几十万。重启后，业务侧发现部分订单被处理了两遍甚至三遍，还有一小部分订单在最终结果里始终对不上账，看起来就像消息“丢”了。
这种场景在中小团队里太常见了。处理过程里每个人都在猜：有人说 Broker 端磁盘 IO 有问题，有人说生产者的重试机制在乱序投递，还有人干脆怀疑网络抖动把数据冲掉了。实际上所有表象都指向同一个源头：消费组成员频繁变动，导致分区在消费者之间来回交接，而交接期间 offset 的提交节奏完全被打乱。积压、重复、丢失，只是同一枚硬币的三个面。
1.2 为什么大家习惯性先怀疑 Broker 和生产端
我后来复盘过很多次，发现大家一开始都搞错方向，本质上是因为对 Kafka 的“高可用”印象太深了：既然消息是持久化在 Broker 上的，那问题怎么会出在消费端呢？这个直觉恰恰是最坑人的地方。
Kafka 确实把消息安全地存在了分区里，但“消息存在”和“业务正确处理了消息”之间，隔着一整条消费链路。这条链路上，重平衡就像一个天然的中断开关，它一触发，所有消费者都要停手、报数、等分配。很多消费端代码在“正常处理”时看着没问题，一旦被重平衡打断，隐藏的 bug 就全暴露出来了。所以，看问题不要总盯着数据有没有丢，先看消费组的“组织状态”是不是一直在动荡。
2. 先搞懂 Rebalance 是什么：消费组“分地盘”背后的两个协议
2.1 消费组协调机制：谁来决定分区往哪放
Kafka 消费组本质上是一个协作小组：组内每个消费者负责若干个分区，且一个分区同一时刻只能被组里的一个消费者持有。这个分配关系不是写死的，而是由一个叫做“组协调器”的角色在每次组状态变化时重新计算。什么时候算“状态变化”？有新消费者加入、有消费者主动退出、有消费者被判定死亡、订阅的主题发生变化，这些都会触发一次重新计算。
计算过程大致是这样的：协调器收到变化信号后，让组内所有消费者先加入一轮“报数”，大家把自己的信息上报；组里会选出一个 leader 消费者，由它根据当前成员列表和订阅信息算出新的分区分配方案；然后协调器把方案分发给每个成员。这整个流程对消费端来说就是“停摆—报数—领任务—恢复”，中间任何一环慢一点，都会直接影响消息处理的连续性。这个“停摆再分配”的过程，就是 Rebalance。
它不是故障，而是 Kafka 为了维持“每个分区同一时刻只被一个消费者消费”这个一致性承诺必须付出的协调成本。问题从来不是它会发生，而是它发生的频率和波及范围，比大多数人预期的要高得多。
2.2 Eager 与 Cooperative：一代协议的差距
很多人不知道，重平衡协议是分代际的。老版本客户端默认使用 Eager 模式：只要组里任何一个成员变动，组内所有消费者必须先把手上所有的分区全部撤销，然后所有人一起重新加入组，等分配结果下发后再恢复消费。你可以想象一桌人吃饭，只要有一个人去上厕所，整桌人必须全部放下筷子重新等菜上齐——这在早期版本里就是常态。这种全员停摆式的重平衡，是积压和重复的大温床。
Kafka 2.4 之后的版本引入了 CooperativeStickyAssignor，支持增量重平衡：只有真正被转移的分区会被撤销，其余分区继续由原消费者持有，消费者之间不需要全员“停摆”。这个协议的意图很好，但现实里有个尴尬：很多团队升级了 Broker 和客户端版本，却始终没改消费者的partition.assignment.strategy配置，依然默认走老协议。等于手里拿着新武器，还按老规矩打。
2.3 一个必须先纠正的认知
在往下深挖之前，先把一个误会拆掉：Rebalance 本身不会“吃掉”任何消息。数据在 Broker 上一直好好躺着，分区不会因为被重新分配就清空数据。丢失、重复、积压之所以和 Rebalance 绑定出现，是因为它触发了消费端的三条连锁反应：消费停摆导致积压，offset 提交时机与分区交接错位导致重复，错误的提交配置在重平衡后导致消费进度被“跳过”，看起来就像是丢了。
把这三条链路理清楚，你再看自己之前的排查动作，就知道哪些是多余的。这也是这篇文章写下去的骨架：先讲积压怎么被触发，再讲重复发生在哪两个窗口，最后讲“丢数据”到底是怎么配合出来的，然后给你一套完整的定位链路和治理清单。
3. 积压的真相：Rebalance 期间消费真的停摆了
3.1 分区撤销后的消费真空期
积压最直接的原因就是消费停摆。一次典型的 Eager 重平衡，从触发到消费者重新拿到分区分配，至少要经历两轮 RPC（JoinGroup 加 SyncGroup），再加上 leader 计算分配方案的时间。这个窗口通常有几百毫秒到几秒，组里消费者越多、分区越多，时间就越长。
关键问题在于，这段真空期内，所有消费者都在“报数”等待，没有一个人拉取消息。只要你的消费速率不足以在恢复之后迅速把这段缺口补上，lag 就会增长。更麻烦的是，如果重平衡频繁发生，两次重平衡的间隔比“追回 lag 所需的时间”还短，那么 lag 就永远追不上，积压只会越滚越大。我见过某团队把session.timeout.ms调成很小的值，消费者 GC 稍微一停顿就被判死，整个下午 lag 曲线像锯齿一样，报警十分钟一次，那才叫真正的折磨。
3.2 重平衡风暴：积压只涨不降的元凶
比单次重平衡更可怕的是重平衡风暴。简单说，就是一次重平衡还没彻底结束，下一次触发条件又满足了，消费者永远在“加入组—同步分配—消费—被踢—再加入组”的循环里打转。
最常见的诱因是超时参数互相踩踏：消费者处理一批消息耗时太长，超过了max.poll.interval.ms的上限，被协调器判定为“已经死了”；但它其实还活着，处理完之后继续 poll，于是又触发新一轮全员重平衡。你试图加机器缓解积压，结果新消费者一加入就再次触发重平衡，反而扩大了崩溃窗口。这种场景下，加机器不仅没帮助，还经常把问题放大。
3.3 从 lag 曲线形态一眼认出来
如果你有监控，判断积压是不是重平衡引起的非常简单：看 lag 的曲线形态。重平衡导致的积压，lag 曲线通常是典型的台阶式上涨——上涨发生在重平衡发生的时刻，随后消费恢复、lag 有一段平稳甚至缓慢下降，然后突然再次上涨。每次台阶的上涨节点，和消费者日志里的 Preparing to rebalance group 能一一对上。
所以遇到 lag 告警，别再先去看 Broker 的吞吐和磁盘了。先把那个时间段的重平衡日志拉出来，如果一个告警窗口里夹着三五次重平衡，那积压的根因基本就锁定了。
4. 重复消费的两个高发窗口：poll 与 commit 之间、新旧主人交接之间
4.1 高发窗口一：处理完成与提交 offset 之间的空档
Kafka 默认的消费语义是 at-least-once，即“先处理后提交，宁可重复不可丢失”。但很多人把这个原则理解成了口号，真正写代码时根本没有控制好“提交点”。最常见的错误姿势是：poll 到一批消息，丢给一个异步线程池去处理，然后立刻在主线程上调用 commitAsync 提交 offset。
这里的问题非常隐蔽：你的 offset 提交的是“已经 poll 出来的位置”，而不是“已经处理完的位置”。异步线程可能还在处理这批数据，offset 却已经往前走了。一旦这个间隙里发生重平衡，新接手的消费者会从已提交的位置继续读，那批没处理完的消息自然会被另一个消费者重新处理一遍。这不是概率问题，只要处理耗时大于提交间隔，重复就是必然事件。想彻底堵住这个窗口，要么同步处理完再提交，要么用“处理完一批记录后再提交该批最后一条的 offset”的方式。
4.2 高发窗口二：新旧消费者交接分区的那一瞬间
第二种重复发生在分区换主的时候。即使你很严格地先处理再提交，依然存在一个难以避免的间隙：消息处理完了，但 offset 还没来得及提交，消费者就被踢出了组，触发了重平衡。此时这条消息的 offset 还停留在原位，新接手的消费者会从它开始重新消费一遍。
要理解这个窗口，你得接受一个事实：Kafka 的 offset 提交本质上是异步、滞后的，它永远不可能精确到“刚好处理到哪就提交到哪”。重平衡的作用只是把这个滞后暴露出来。所以严格来说，重复消费无法被完全消灭，只能靠下游的幂等逻辑去兜底。这也是为什么我一直强调：幂等设计不是选择题，而是必答题。
4.3 如何验证重复来自 Rebalance
排查重复消费时，先别急着怀疑生产端重试。最有效的方法是在消费逻辑里打印“分区—offset—消息 ID”的组合日志，然后去检索同一个消息 ID 出现多次的记录，看它们的消费时间间隔。如果时间间隔很短，而且中间恰好夹着一次重平衡日志，那基本可以锁定是 Rebalance 导致的重复：同一批消息被旧消费者处理到一半，被新消费者接手后又从头处理了一遍。
如果同一消息 ID 的两次消费时间间隔很长，比如隔了几分钟甚至几小时，那才需要考虑生产端是否在重复投递。先把自己这一侧确认干净，再去怀疑上游，这是排错的基本顺序。
5. “丢数据”的真相：不是 Rebalance 吃了消息，而是配置配合它掩盖了 offset
5.1 最容易配合 Rebalance 造成“丢失”的三种姿势
先说结论：Kafka 本身极少丢数据，绝大多数“感觉丢了”的场景，其实是消费端把消费进度提交到了消息前面，重平衡只是那个把矛盾暴露出来的导火索。我整理了三种最容易配合 Rebalance 造成“丢消息”的姿势，你可以对照检查自己的代码。
第一种：开着默认的enable.auto.commit=true，却用多线程异步处理。默认的自动提交每 5 秒会把 poll 返回的 offset 提交一次，根本不管业务逻辑有没有跑完。一旦这 5 秒窗口内发生重平衡，新消费者就会从已自动提交的位置开始消费，中间被跳过的消息就再也不会被处理了。
第二种：在处理过程中依赖了外部状态，比如先写数据库再发通知，但消费进度却提前提交了。重平衡后整个任务恢复时，外部状态已经部分完成，消费进度却从中间开始，后半段逻辑不会再触发，业务上看起来就是“丢了”。
第三种：为了追求吞吐使用 commitAsync，却在回调里忽略了异常。commitAsync 不阻塞，但如果提交失败后紧接着发生重平衡，offset 就彻底对不上账了，丢失窗口会被无限放大。
5.2 一张表看透消费语义
我把常见提交方式组合和最终语义整理成了下面这张表，你可以对照自己的工程排查：
| 提交方式 | 处理方式 | 实际语义 | 重平衡后的风险 |
|---|---|---|---|
| enable.auto.commit=true（默认） | 异步多线程处理 | 混合语义，取决于时序 | 可能跳过未处理消息，表现为丢失 |
| enable.auto.commit=false + commitAsync | 同步处理 | at-least-once，有提交失败风险 | 可能重复，基本不丢 |
| enable.auto.commit=false + commitSync | 同步处理 | at-least-once，最稳 | 可能重复，不丢 |
| enable.auto.commit=false + 手动提交已处理位置 | 并发受控 | 接近 at-least-once，窗口可控 | 重复窗口小，不丢 |
看清这张表你就会明白：真正“丢消息”的时候，你要改的不是 Kafka 的某个神秘参数，而是消费代码里的提交策略。重平衡只是把问题从“隐性”变成“显性”而已。
6. 一条完整的 Rebalance 定位链路：从日志、指标到触发原因
6.1 第一步：在日志里还原重平衡事件时间线
几乎所有 Kafka 客户端都会在日志里记录重平衡的关键节点，你只需要按 groupId 过滤关键日志，就能还原每一次重平衡的时间线和大致原因。常用的关键字有几组：Preparing to rebalance group 表示开始重平衡；Successfully joined group with memberId 表示消费者成功加入；Assignment received from leader 表示收到了分配方案；Member consumer-x has left group 表示成员离开，这里要区分是主动退出还是超时被踢；还有 Group coordinator is unavailable 之类的协调器异常。
把这些日志按时间排序，再和报警时间点、lag 突变点做关联，问题范围就能从“整个集群”迅速缩小到“某一次重平衡事件”上。这一步做完，大部分场景你已经能有初步判断了。
6.2 第二步：用成员状态和 JMX 指标缩小范围
接下来用kafka-consumer-groups.sh查看消费组的当前状态。重点看两列：成员数是否经常波动，以及当前活跃的 consumer 数量和实际部署的实例数是否一致。如果成员数在频繁增减，说明有消费者在反复注册和退出，这是重平衡风暴的直接信号。
再配合 JMX 指标观察消费端的心跳情况，重点看consumer-coordinator-metrics里的心跳响应耗时上限，以及会话超时相关计数。如果心跳耗时在持续走高，说明消费端进程可能在做大量 GC 或底层 IO 卡顿；如果超时计数在增长，说明心跳已经频繁发不出去。
6.3 第三步：锁定真正的触发原因
重平衡的触发原因无非四类：新增消费者（扩容操作）、消费者正常退出（发布或下线）、session 超时（GC、网络抖动、进程卡顿导致心跳丢失）、poll 超时（单批处理耗时超过max.poll.interval.ms）。到这一步，你只需要回答一个问题：出问题的时间点，是有人动了部署，还是处理变慢，还是进程出现了明显停顿？
我自己的习惯是拉三个维度的数据对比：部署变更记录、消费者进程的 GC 日志、以及该时段的网络重传率。这三样数据里任何一样出现异常，都能解释九成以上的重平衡事件。找不到异常的情况也有，那种时候往往是某个消费者进程被人为 kill 掉但监控没覆盖到，属于另一类问题。
7. 根除 Rebalance 隐患的治理清单：参数、协议、静态成员与工程习惯
7.1 三个核心参数的正确配合关系
先看一组最容易被人单独乱调、实际上必须放在一起理解的参数：
| 参数 | 默认值 | 作用 | 调优方向 |
|---|---|---|---|
| session.timeout.ms | 45000（老版本 30000） | 超时收不到心跳则判定消费者死亡 | 非特殊场景不要乱调小 |
| heartbeat.interval.ms | 3000 | 心跳发送间隔 | 保持小于 session 的 1/3 |
| max.poll.interval.ms | 300000 | 两次 poll 最长间隔，超过则主动离开组 | 根据单批处理耗时的上限设置 |
它们三个是一个组合拳：session.timeout 管“心跳层面是否还活着”，max.poll.interval 管“业务层面是否还活着”。如果你的单批处理耗时经常逼近 5 分钟，与其把 max.poll.interval 调到无限大，不如把max.poll.records调小，让单批消息量减少、单批处理耗时下降。这才是更健康的解法，本质上是让“处理能力”去匹配“拉取速度”，而不是迁就处理能力去无限放宽超时。
7.2 升级 CooperativeStickyAssignor：改动最小收益最高
如果你的客户端版本在 2.4 以上，却还在用默认的 RangeAssignor，请尽快把partition.assignment.strategy改成 CooperativeStickyAssignor。它最大的价值，是把重平衡从“全员停摆”变成“局部调整”，只撤销受影响的分区，其余分区继续由原消费者持有。受波及的分区少了，积压和重复的窗口自然就小了。
这一步是投入产出比最高的优化，基本就是改一个配置项的事。不需要动代码逻辑，不需要调整消费架构，改完重启消费者就能生效。很多团队升级了 Kafka 版本却漏了这一步，属于典型的“拿着金饭碗要饭”。
7.3 静态成员机制：让重启不再引发全员重平衡
另一个容易被忽略的升级是静态成员机制。普通消费者每次重启都会生成新的 memberId，协调器会认为这是一个新成员加入，从而触发一次全员重平衡。通过给每个消费者配置group.instance.id，客户端重启后会以同一个身份回来，只要在session.timeout时间内归组，协调器会直接恢复旧身份对应的分区分配，不再触发全员重平衡。
这个机制特别适合“发版重启防抖”的场景。你经常能看到消费端一重启、整个组的 lag 就跳一下，配置了group.instance.id之后，这种跳变会被明显抑制。注意每个消费者实例的 instance.id 必须唯一，不能多个进程共用同一个 ID，否则会出现成员冲突。
7.4 幂等、监控与处理耗时的三个工程习惯
最后说代码层之外的事，这三样属于“平时不显眼，出事保命”的习惯。
第一，所有下游消费逻辑必须保证幂等。Kafka 不承诺也不打算给你完美的 exactly-once 体验，把幂等当成唯一的可靠兜底，写进每一个消费处理函数里。判断是否重复的标准要基于业务唯一键，而不是依赖 Kafka 的消息 ID。
第二，监控上至少要有三张图：消费组 lag 趋势、消费者成员数变化、重平衡事件时间点。这三张图叠在同一个时间轴上看，任何异常都能快速定位。成员数变化图是最容易被忽略的，但恰恰是它能第一时间告诉你“组在动荡”。
第三，把消费端处理耗时的 p99 纳入日常巡检。大部分重平衡不是参数配错了，而是处理端突然变慢把 poll 超时逼出来了。你只要盯着处理耗时的长尾，就能在真正出大事之前提前介入。
8. 宁可多看一眼重平衡日志，也不要一头扎进监控面板
8.1 我的标准排查 SOP
如果再把那晚的场景重来一次，我现在的第一反应已经变了：不会再打开 Broker 大盘乱翻，而是按一条固定的顺序走。
第一步，打开消费组日志，过滤 Preparing to rebalance group，把重平衡事件的时间点全部列出来；第二步，对照 lag 曲线的台阶式上涨，确认消费停摆窗口；第三步，看消费组成员数有没有频繁波动，判断是不是有实例在反复上下线；第四步，检查 session 超时和 poll 超时的相关指标，确认触发原因属于哪一类。这套顺序走完，八成以上的积压、重复、丢失问题都已经有答案了，剩下的两成才需要去翻生产端的重试日志和网络抓包。
8.2 复盘过太多事故后留下的三条经验
第一条：不要在故障时重启消费者来“试探”。没有确认重平衡原因之前，每一次重启都在给系统增加新的重平衡事件，只会让情况更乱。第二条：参数调优要成组地看，单改 session.timeout 或者单改 max.poll.interval 都会引发新的并发症，三个参数必须放在一起评估。第三条：所有的消费处理函数，从第一天就用最笨的“同步处理+幂等”方式，不要为了那点吞吐把语义复杂度留到线上事故里买单。
重平衡这个东西，平时看就是一个日志关键字，可它像一个放大器，会把消费端代码里所有不严谨的地方放大给你看。不要怕它，但一定要尊重它。搞懂它什么时候触发、触发后会发生什么，比你背诵一百个参数默认值都有用。下次再遇到消息乱象，先问自己一句“是不是又 rebalance 了”，再动手排查，你会感谢这个习惯的。
