📚 课程目录第2章重平衡的代价

2、重平衡的代价：Stop The World 现象、消费停滞、重复消费与数据不一致

重平衡（Rebalance）听起来像是个优雅的协调机制，对吧？

但说实话，在线上环境里，它更像是一场「小型灾难」。我见过不少团队，Kafka 集群跑得好好的，突然消费端就卡住了。查了半天，罪魁祸首就是一次意外的重平衡。

这一节，我们来扒开重平衡的底裤。看看它到底带来了哪些代价。

先问一个问题：重平衡发生时，消费者在干嘛？

答案是：所有消费者都必须停止消费，等待重平衡完成。这就是所谓的 Stop The World（STW）现象。

在 Kafka 的旧版本（0.10.x 及之前）中，这个现象尤其明显。所有的消费者都会在 poll() 方法调用时被阻塞，直到协调者（Coordinator）完成分区分配。这个过程里，你的消费线程就像被按了暂停键。

核心影响：

我记得有一次，一个业务团队反馈他们的实时推荐系统每隔几分钟就卡顿一次。我上去一看日志，发现消费者组在频繁触发重平衡。每次 STW 持续 3-5 秒，但架不住它一小时触发几十次。用户端看到的推荐结果，直接变成了「加载中...」的转圈圈。

避坑指南：

我曾经遇到过因为消费者处理逻辑耗时过长，导致 session.timeout.ms 频繁超时，进而触发重平衡。后来我把 max.poll.interval.ms 调大了一倍，同时优化了业务代码，才把这个问题压下去。

STW 带来的直接后果就是消费停滞。你想想看，一个 10 个消费者的组，本来每秒能处理 10 万条消息。重平衡一来，这 10 万条瞬间变成 0。等重平衡结束，消费者重新分配分区，又得重新建立连接、拉取数据。

这个「恢复期」其实比 STW 本身更可怕。因为重平衡完成后，消费者需要重新定位 Offset，重新拉取数据。这段时间的吞吐量是逐步爬升的，而不是瞬间恢复。

我习惯用一张图来描述这个过程：

你看，从 T1 到 T3 这段时间，消费能力都是受损的。如果你的业务对延迟敏感，比如风控、实时计费，这几秒钟的停滞可能就意味着大量订单超时或数据堆积。

重平衡最让人头疼的，不是慢，而是重复消费。

为什么会重复消费？说白了，就是 Offset 提交的时机出了问题。

假设一个消费者正在处理一批消息，处理到一半，重平衡发生了。这时候，它还没来得及提交 Offset。重平衡完成后，这个分区被分配给了另一个消费者。新消费者从上次提交的 Offset 开始拉取，于是那些已经处理过但没来得及提交 Offset 的消息，又被拉出来重新处理一遍。

注意：

重复消费不是「可能发生」，而是「几乎必然发生」。只要你的消费者启用了自动提交（enable.auto.commit=true），并且处理时间大于提交间隔，重平衡就一定会导致重复消费。

我习惯用一张表格来对比不同提交策略下的重复消费风险：

你看，没有一种策略能完全避免重复消费。唯一靠谱的方案，是让消费端具备幂等性。也就是同一条消息处理多次，结果和只处理一次是一样的。

避坑指南：

我曾经在一个订单处理系统里，因为没做幂等，重平衡后导致同一个订单被扣了两次库存。后来我加了一个「消息去重表」，用消息的唯一 ID 做数据库主键，才彻底解决了这个问题。嗯，这个坑踩得值。

重复消费只是表象，更深层的问题是数据不一致。

想象一个场景：你的消费者在处理一批消息，这批消息里有「创建订单」和「更新订单状态」两条。如果重平衡发生在「创建订单」处理完、「更新订单状态」还没处理的时候，会发生什么？

重平衡后，新消费者从 Offset 重新拉取，它可能先处理「更新订单状态」，但此时订单还没创建。于是，更新失败。等它再处理「创建订单」时，状态更新已经丢了。

这就是数据不一致——消费的顺序被重平衡打乱了。

数据不一致的典型表现：

我个人习惯在消费端做两件事来应对这个问题：

你想想看，如果重平衡导致数据不一致，排查起来有多痛苦？日志里全是正常记录，但业务数据就是不对。我见过一个团队花了整整一周，才定位到是重平衡导致的乱序问题。

最后，我用一张图来总结重平衡的四大代价：

这四大代价，每一个都足以让你的线上系统出大问题。所以，理解重平衡的代价，不是为了害怕它，而是为了在设计和运维中，有针对性地去规避它。