📚 课程目录第1章重平衡全景图

一、重平衡全景图：什么是消费者重平衡？为什么它如此重要？重平衡的触发条件有哪些？

各位同学，咱们今天聊一个 Kafka 里绕不开的话题——消费者重平衡。我做了这么多年分布式系统，见过太多因为重平衡翻车的案例。说白了，重平衡就是 Kafka 消费者组里的一次「重新洗牌」。

想象一下这个场景：你有一个消费者组，里面 3 个消费者在同时消费一个 6 分区的主题。突然，其中一个消费者挂了。剩下的两个消费者需要把原来三个人的活重新分一下——这就是重平衡。

用官方的话说：重平衡（Rebalance）是 Kafka 消费者组内所有消费者重新分配分区所有权的过程。它保证了每个分区在同一时刻只被组内的一个消费者消费，从而维持消息的顺序性。

核心要点：重平衡的本质是「分区所有权转移」。每次重平衡，消费者组都会进入一个短暂的不可用状态，期间无法消费任何消息。

我个人习惯把重平衡比作「办公室座位调整」。你想想看，本来大家都有固定工位，突然有人离职了，HR 就得重新排座位。排座位期间，所有人都得站着等——这就是重平衡的代价。

这个问题我问过不少刚入行的同学。有人觉得重平衡就是个「自动容错」机制，没什么大不了的。但我在项目中遇到过好几次，重平衡引发的消费延迟直接把线上业务搞崩了。

重平衡的重要性体现在三个层面：

但这里有个坑——重平衡本身是有代价的。我曾经在线上环境看到，一次全量重平衡导致整个消费组停顿了 30 多秒。对于实时性要求高的场景，这简直是灾难。

避坑指南：我曾经接手过一个项目，他们每 5 分钟触发一次重平衡，结果消费延迟从秒级飙升到分钟级。后来一查，是消费者心跳超时设置得太短。记住：重平衡不是免费的午餐，每次重平衡都是对系统性能的一次「抽血」。

搞清楚了「是什么」和「为什么」，咱们来看看「什么时候会触发」。我总结了 5 种常见场景：

嗯，这里要注意：分区数量减少不会触发重平衡。Kafka 不支持减少分区，只能增加。这是设计上的一个取舍，我个人觉得挺合理的——减少分区涉及数据迁移，复杂度太高。

为了让你更直观地理解，我画了一张流程图。这张图我改了好几版，力求把每个步骤都讲清楚。

从图上你能看到，重平衡分三个阶段：

小技巧：我个人习惯在监控里重点关注 JoinGroup 阶段的耗时。如果这个阶段经常超过 5 秒，说明你的消费者组里可能有「慢成员」——要么是 GC 问题，要么是网络抖动。我曾经用这个指标定位过一个隐藏了两周的 Bug。

Kafka 提供了两种重平衡策略，我简单对比一下：

策略	特点	适用场景	缺点
Eager Rebalance	所有消费者先撤销分区，再重新分配	分区数少、消费者少	全量停顿，影响大
Cooperative Rebalance	逐步撤销、逐步分配，不停顿	分区数多、消费者多	实现复杂，需要客户端支持

你想想看，Eager 就像公司全员大搬家——所有人都得先搬出来，再重新搬进去。Cooperative 则是「谁先收拾好谁先搬」，互不干扰。我建议新项目直接用 Cooperative，虽然配置上多一步，但线上体验好太多了。

重平衡是 Kafka 消费者组的核心机制，也是最容易出问题的地方。记住三个关键点：