1. 先聊聊 Kafka Consumer Rebalance 到底是什么

1.1 从“消费者组”说起

在讲 Rebalance 之前，我习惯先跟刚接触 Kafka 的朋友确认一个概念：消费者组（Consumer Group）。Kafka 的消息不是凭空推给消费者的，而是消费者主动到某个 Topic 的分区里去拉取。一个消费者组就是一组共同消费一个或多个 Topic 的客户端实例，这些实例拥有相同的 group.id。Topic 的每个分区，在任意时刻只能被同一个组内的一个消费者实例消费，但一个消费者可以承担多个分区。正是因为“分区-消费者”之间这种多对多的分配关系，才有了 Rebalance 这个不得不讲的机制。

为什么非要搞一个组？最直白的理由是分布式消费的伸缩性。你想处理每秒几十万条消息，单机肯定吃不消，那就多开几个消费者进程。它们一起把 Topic 的所有分区瓜分掉，每个进程负责其中一部分，同时还能互相备份——某个实例挂了，它负责的分区可以由组内其他成员接手。这种模型的前提就是，组内的“谁消费哪个分区”是一个动态分配的协议结果，而这个结果的重算过程，就是 Rebalance。

1.2 Rebalance 带来的痛

做过线上运维的老哥应该都体会过那种感觉：本来一切正常，某个消费者进程内存溢出一重启，整个组的消费就卡了几秒，然后看到一堆“Partition rebalance”“Assignor”的日志。如果 Topic 分区数多、消费者多，卡顿可能从几秒拉长到半分钟。更诡异的是，有时候只是加了一个新消费者实例，所有消费进程都会发生一次“大洗牌”，期间什么都不消费。

这类问题背后的本质，就是 Kafka 的消费协调器（Consumer Coordinator）在做一次全量重新分配。Rebalance 本身不是 Bug，而是 Kafka 保证 Group 内消费一致性和高可用的手段，但粗暴的经典 Rebalance 会带来全组暂停、重复消费和消费延迟增大等问题。所以理解它的机制、触发条件、分配算法，以及如何用静态成员、协作式 Rebalance 等手段把它对业务的影响降到最低，是 Kafka 使用者的必修课。

这篇文章我会先讲清楚为什么必须要有 Rebalance，再走一遍从 JoinGroup 到 SyncGroup 的完整协议流程，接着对比几种分区分配策略，然后讲经典与协作式两种 Rebalance 模式的区别，最后给出一套我在实际生产环境验证过的参数和排查方法。全程会带一些我踩过的坑和日志截图式的细节描述，希望对正在被 Rebalance 折磨的朋友有点帮助。

2. 为什么 Kafka 设计成“会 Rebalance”

2.1 动态扩缩容的代价

Kafka 把参与消费的节点当成是一个随时可能变化的状态池。你今天启动 3 个消费者，明天想扩到 10 个，后天某个机器维护要缩回 6 个，这期间还要应对进程被 kill -9、OOM、网络抖动等意外。如果 Kafka 像传统队列一样，让每个消费者启动时永久绑定一个分区队列，那么扩缩容和维护就会变成一场噩梦：新实例没分区可消费，老实例的负载永远降不下来。

所以 Kafka 引入了会“重新分组”的协调机构。消费者实例启动后，会向 Group Coordinator 报到，报到的同时带上自己还活着的凭证。Coordinator 一旦发现组的成员列表变了，也就是有成员新加入或离开，就会触发一次 Rebalance，把当前所有存活成员召集起来，重新对全部分区进行“分配投票”。这个设计的核心代价就是：为了灵活性，你必须接受群体性的状态重置。

说实话，这种“全量重建”的思路很符合分布式系统的经典权衡。类似 Java 里 CopyOnWriteArrayList，写操作会复制整个底层数组，换来的是读线程的无锁并发。Rebalance 也一样，用一次全组同步换来了未来任意时间点自由扩缩容的弹性。问题只在于，这个“全组同步”过程里旧分配立刻失效，所有消费者都会先撤销自己手上的分区，等新结果出来再接，这就导致了消费窗口短暂关闭。

2.2 Rebalance 触发的几种典型场景

我把它整理成四大类，方便记忆：

1. 成员数量变化：组内消费者实例加入或离开。最常见的离开是进程退出、OOM 重启、容器扩缩容。注意消费者优雅关闭与 kill -9 的差别，优雅关闭会发送离开组的请求，所以 Rebalance 更快；直接 kill 则会等 Session 超时被踢出，Rebalance 更慢且期间分区无人消费。

2. 订阅 Topic 变化：消费者组订阅的 Topic 列表发生变化，比如增加订阅了一个新 Topic，或者原有 Topic 被删除。Coordinator 看到 Metadata 变化后，为了保证分配的一致性，会重新触发 Rebalance。

3. Topic 分区数量变化：这个特别容易踩。很多人只增加 Topic 的分区数，不关注消费端。Kafka 的分区数量一旦增加或减少，组内的消费映射必须重算，因为分区到了新维度。

4. 消费参数 / Rebalance 相关超时：比如 Session 超时后 Coordinator 判定某个成员下线，或者协调器自身发生迁移（Coordinator 所在 Broker 节点切换）。还有消费端调用了某些可能触发 Rebalance 的 API，例如重新订阅 subscribe(Collection)。

第 4 类里有个细节要强调：Session 超时和 MaxPollInterval 超时对 Rebalance 的影响路径不一样。Session 超时是 Heartbeat 线程层面，如果心跳网络不通或者 GC 长停顿，Coordinator 会认为成员死亡，直接踢出。MaxPollInterval 则是告诉 Coordinator“这个成员虽然心跳还在，但太长时间没有调用 poll 拉数据了，我怀疑它处理不过来”，也会被移除。所以这两个参数调不好，Rebalance 的触发频率会成倍上升。

3. Rebalance 的完整过程详解

3.1 第一阶段：JoinGroup，全组“报到”

先明确一个概念：每个消费者组会有一个 Group Coordinator，它是 Kafka 某个 Broker 上的一个内部组件，专门管这个组的成员关系。Consumer 在启动时通过请求的 Metadata 信息找到 Coordinator，然后发送 JoinGroup 请求。

JoinGroup 请求里带着自己支持的分配策略列表，以及自定义的 MetaData（比如订阅的 Topic 列表）。Coordinator 收到第一个成员加入请求后，会启动一个“延迟选举”，给其他现存成员一个等待窗口。窗口结束前没有加入的成员会被视为掉线，窗口结束后 Coordinator 从存活的成员里选一个 Leader。

很多人以为消费者组 Leader 是特殊角色，其实它只是代表全组执行分区分配算法。Leader 会收集所有成员的订阅信息和 MetaData，用组内协商出的分配策略（比如 RangeAssignor）算出每个成员该消费哪些分区，然后把结果返回给 Coordinator。而普通成员会从 JoinGroup 响应中拿到 Leader 的信息，进入下一阶段。

这里有个细节值得记一下：如果一个组是新创建的，第一个消费者会等满 JoinGroupTimeout 才会拿到分配结果吗？答案是不会。协调器会设置一个 RebalanceTimeout，在这个时间窗口内尽量收集更多成员，避免刚启动一个客户端就立即分配，然后在下一个客户端瞬间再触发新 Rebalance。这个初始等待的时间实际由协调器配置决定，但客户端的 join.group.timeout.ms 也会影响这个过程。

3.2 第二阶段：SyncGroup，分配结果同步

JoinGroup 阶段确定了“谁是新 Leader”和“组内存活成员列表”，但此时还没有真正确定分区分配。接下来所有成员都会向 Coordinator 发送 SyncGroup 请求。

Leader 会把在本地算好的分配方案（一个 Map<memberId, List<分区>>）放在 SyncGroup 请求里上传给 Coordinator；其他成员则发送空的 SyncGroup 请求，等待 Coordinator 返回属于自己的分配结果。Coordinator 作为“同步中枢”会把 Leader 的分配结果缓存下来，然后按 memberId 分别下发给每个成员。所有成员拿到结果后，开始重新订阅对应的分区并消费。

这个阶段很关键的一点是，如果某个成员在 JoinGroup 之后、SyncGroup 之前退出了，Coordinator 会发现这个问题并可能立即触发新一轮 Rebalance。因为分配结果已经生成，但这个成员已经不在了，它的分区没人接管。所以你会看到有时候日志里出现连续的 Rebalance：第一次是因为成员 A 加入，第二次是因为成员 A 在 Sync 阶段前又退出了。这种“两次连跳”在生产环境很常见。

3.3 第三阶段：消费恢复，Heartbeat 持续保活

SyncGroup 完成后，消费者正式进入正常消费状态。这时候每个消费者需要周期性向 Coordinator 发送 Heartbeat 请求，证明自己还活着。Coordinator 根据心跳来判断是否需要重新触发 Rebalance。

Kafka 从某个版本开始把心跳和消息拉取放在不同的线程里，所以即使你的处理逻辑比较慢，心跳仍然能维持住，不会因为一次 poll 超过时间就触发 Rebalance。但心跳保持并不意味着万事大吉，Coordinator 还会检查你是否在 max.poll.interval.ms 内持续调用 poll 方法。如果你一直不 poll，即使心跳正常，协调器也会认为你“消费进度卡住”，依然会把你的成员移出组，触发 Rebalance。

所以第三阶段其实可以概括成一句话：用“双保险”机制（心跳存活 + poll 活跃）维持成员身份，任何一条断掉都会重新触发全组分配。理解了这一点，后面调参数就不会乱调了。

4. 分区分配策略的选择

4.1 三种内建策略速览

Kafka 默认提供了三种分区分配策略，分别是 RangeAssignor、RoundRobinAssignor 和 StickyAssignor。绝大部分时候我们直接用客户端的默认配置就行，但如果真要手动指定 partition.assignment.strategy，那就要知道它们各自的脾性。

Range 策略的逻辑是按 Topic 逐个分配：对每个 Topic 的分区排序后，用总数除以消费者数，余数分给前面的消费者。它的最大问题是多个 Topic 叠加时容易出现某一个消费者负载特别高。比如你有两个 Topic 都只有两个分区，但组里只有三个消费者，Range 会让第一个消费者拿到每个 Topic 的一个分区，总共两个分区，而后面两个消费者只能拿零个，明显失衡。

RoundRobin 策略的逻辑是把组内所有订阅 Topic 的分区合并成一个大的分区列表，轮询分配给各个消费者。它比 Range 平均，但在分配结束前无法保证某个消费者的分区数量稳定，而且每次 Rebalance 可能会把之前的分区全部撤销再重新分配，对消费中断不友好。

Sticky 策略是后来推出的，核心目标有两个：一是尽量保持上一次分配的结果，减少不必要的分区迁移；二是在重新分配的“变化”中尽量平衡。我第一次用 Sticky 时，最直观的感受是加一个消费者进来后，它拿到的分区很少，而不是像 RoundRobin 那样把整个棋盘推翻重下。这个策略在较新的客户端里已经是推荐配置。

4.2 我踩过的分配策略坑

有次我在某个项目里遇到一个诡异现象：消费者组里有三个实例，但其中一个消费者几乎消费不到消息，另外两个压力巨大。排查后发现，我们当时还在用老版本的客户端，默认策略是 Range。而那个 Topic 有 4 个分区，订阅它的一共有 3 个消费者。用 Range 一算：4 除以 3 = 1 余 1，第一个消费者得 2 个分区，后两个各得 1 个。表面看着还行，但如果我们同时订阅了另一个只有 2 个分区的 Topic，第一个消费者又额外拿 1 个，后两个各拿 0 个。叠加起来，第一个消费者负担越来越重，后两个肉眼可见的闲。

换成 RoundRobin 之后好了一阵，但后来因为某个消费者处理太慢，频繁触发 Rebalance，每次 Rebalance 完所有分区都重新分配了一遍，连之前的 offset 都有短暂重复消费。而且 RoundRobin 不保证“粘性”，运行几小时后只要加一台机器，全组又会发生大范围分区迁移。直到我把客户端升级到支持 Sticky 的版本，并将分配策略显式配置为 StickyAssignor，抖动才明显降下来。

这里给一个判断思路：如果 Topic 分区数统一、消费者数量固定且对“抖动”不敏感，用 RoundRobin 也可以；如果 Topic 数量多且分区数不齐，或者希望 Rebalance 后的分区迁移尽可能少，优先用 Sticky。分配策略不是玄学，本质就是“均衡性”和“连续性”的取舍，结合自己的消费类型判断即可。

5. 经典再平衡 vs 协作再平衡

5.1 Eager Rebalance 的“Stop-the-world”

经典再平衡模式，也就是 Eager Rebalance，是 Kafka 早期版本以及当前很多老客户端默认使用的模式。它的最大特征是“两步全量重置”：先让所有消费者撤销当前所有分区，停止消费；然后重新加入、重新分配。

用数据库的话讲，这就是一个典型的“Stop-the-world”。所有消费者在 Rebalance 期间都在“休耕”，没有一个人拉消息。如果你有监控，会看到消费延迟在 Rebalance 开始直线上升，结束后慢慢回落。对实时性要求高的业务来说，这种停顿很难接受，尤其是消费者实例数量超过 20 个、分区超过 100 个时，Rebalance 的时间可以到秒级甚至更长。

它也不是没有好处。实现简单、逻辑清晰，所有参与者都从一张白纸开始，不会出现某个消费者手上还持有旧分区就同时拿到新分区导致“双通”问题。所以以前很多踩过坑的老哥宁可接受停顿，也不愿意去用不熟悉的策略。

5.2 Cooperative Rebalance 的分批收敛

协作式再平衡（Cooperative Rebalance）是 Kafka 在新版本中逐步推广的增量模式，核心思想是“分区变更时，只调整受影响的消费者，减少全局停顿”。它的实现依托一个新的协议阶段，在 JoinGroup 和 SyncGroup 之间增加了分区释放的协商过程，消费者先主动上报哪些分区可以释放，然后协调器再决定谁接管。

实际看到的效果是：假设组里有 4 个消费者、16 个分区，现在新增一个消费者，Eager 模式会把 16 个分区全部先撤销，再分配给 5 个消费者；Cooperative 模式则会先让部分消费者释放少量分区，新消费者先接管释放出来的分区，下一轮再继续迁移，直到负载均衡收敛。整个过程里，所有消费者仍然可以处理未释放的分区，消费窗口基本不中断。

不过 Cooperative 并非银弹：它要配合使用 StickyAssignor 才能发挥最大价值，如果仍用 RangeAssignor，只会退化成类似 Eager 的效果。另外旧版本客户端之间协议不兼容，升级时必须保证组内所有消费者的客户端版本一致，否则协调器会回退到旧协议。

5.3 不同版本/客户端的取舍建议

如果你在用一个已经有几年历史的业务系统，第一反应别急着升级。先确认所有消费者客户端版本是否一致，如果混用新老版本，协作式 Rebalance 可能无法启用，甚至出现协议不兼容的报错。最稳妥的办法是统一升级到支持协作式的客户端版本，同时将分区分配策略配置为 CooperativeStickyAssignor，这是兼顾低停顿和分配均衡的最优组合。

如果暂时无法升级，那么请老老实实把经典 Rebalance 的参数调优：把 session.timeout.ms 适当调大，避免偶发 GC 导致误踢；把 max.poll.interval.ms 调大，给慢消费留出缓冲；同时减少不必要的 Rebalance 触发，比如不要频繁修改订阅的 Topic 列表。我见过很多团队因为改动订阅 Topic 导致每小时 Rebalance 几十次，这种情况下升级任何客户端模式都是治标不治本。

6. 让 Rebalance 尽量“无感”的工程实践

6.1 静态成员：让 group.instance.id 稳定消费

传统动态成员模式下，消费者实例只要一重启，或者短暂掉线，就可能触发一次 Rebalance。而且如果进程频繁重启，组内成员 ID 一直在变，每次变化都要重算全部分区。为了根治这个问题，Kafka 引入了静态成员概念，通过配置 group.instance.id 让消费者实例拥有一个固定身份。

设置 group.instance.id 后，消费者重启时不会立即触发 Rebalance，而是带着老身份重新注册。Coordinator 会保留一个短暂的“离席”宽限期，如果在这个宽限期内老实例重新加入，就直接恢复它原来的分区分配，组内其他成员完全无感知。这个宽限期由 session.timeout.ms 控制。听起来很美好，但要注意：静态成员模式下如果实例真的永久下线，那么它的分区会被“霸占”直到 Session 超时，这意味着故障切换速度变慢了。所以在使用时要根据业务容忍度来折中。

我自己的经验是，静态成员适合“有状态或代价昂贵的消费者”，比如某个消费者处理逻辑里维护了本地缓存，或者需要保持与下游的长连接，Rebalance 会导致这些资源重建。这时候一个固定 ID 比快速重新平衡更有价值。

6.2 调好 session.timeout.ms 和 max.poll.interval.ms

这两个参数是 Rebalance 触发频率的“水龙头”。session.timeout.ms 表示协调器等待该消费者心跳的最大时间。大多数线上问题都出在这个值设置不合理：消费者处理一次批量消息耗时较长，导致心跳间隔超过 Session 超时，被误判死亡并触发 Rebalance。

而 max.poll.interval.ms 控制的是两次 poll 调用之间的最大间隔。如果你的处理逻辑耗时超过这个间隔，即使心跳正常，协调器也会认为你卡死。为什么有这个参数？因为心跳线程和业务线程是分开的，业务线程阻塞但心跳仍正常，Coordinator 如果没有这个参数，就永远无法发现处理停滞的消费者。将两个参数调大或者调小，取决于业务处理特点。

我的建议是：先观察你的消费处理耗时，统计 P99 耗时，把 max.poll.interval.ms 设为 P99 的 2 倍以上，再留一点余量给 GC 停顿；session.timeout.ms 可以设为比心跳间隔大很多的值，比如心跳间隔是 3 秒，Session 超时设为 30 秒或 45 秒。不要为了追求“快速故障转移”把 Session 超时设得太小，否则你会用频繁的 Rebalance 来支付代价。

6.3 防止“假死”的消费逻辑调整

除了参数，消费代码本身也常见问题。很多人写 Kafka 消费者，会在 poll 之后做一系列阻塞操作，比如调用远程接口、等待数据库锁，甚至写了个 Thread.sleep(5000)。这样极容易触发 max.poll.interval.ms 超时。

一个很实用的做法是“拉小批，快速交还”：把 max.poll.records 调小，比如一次最多拉取 200 条，保证一次 poll 的处理时间在合理范围内。如果单条消息处理比较重，就用多线程并发处理，但要注意多线程场景下 offset 提交的语义一定不能乱，先启用 enable.auto.commit=false，在真正处理完成后手动提交，否则消息处理失败又提交了 offset，丢数据会看得你怀疑人生。

另一个容易被忽略的是消费者组订阅列表的变化。不要在代码里动态地频繁修改订阅的 Topic 集合，每次修改都会触发一次 Rebalance。如果需要动态控制消费目标，最好在服务启动前就确定好订阅关系，后续变更走发布配置重启消费实例，而不是在运行时调 subscribe。

7. 常见问题速查与排查实录

这里整理一份我在一线运维中经常遇到的 Rebalance 相关问题和排查思路，以及对应的避坑提示。

上面这张表只是方向性参考。真到了定位问题的时候，我一般会先看两类日志：一类是消费者端日志里的“Partition assign / revoke”相关打印，另一类是 Broker 端协调器日志里的“Group ... rebalance”相关打印。对照两者一起看，能很快判断出到底是成员加入/离开触发的，还是 Coordinator 主动发起的。

另外要关注 JVM Full GC 问题。生产环境经常出现“消费者进程还活着，但心跳线程被 GC 暂停打断”的情况，看起来像网络故障，实际是 GC 停顿导致心跳超时。如果你发现 Rebalance 总是周期性出现，时间点正好对应 GC 日志的 Major GC，那就不是 Kafka 的问题，而是 JVM 参数问题，优先优化堆大小和 GC 策略。

还有一个冷门但真实的坑：如果你在容器里用 Host 网络或者 NAT 网络，消费者客户端配置了 advertised.listeners，但 Broker 无法通过这个地址回连。这时候消费者发送 JoinGroup 后可能迟迟等不到响应，或者被协调器判定失联。排查时要记得检查客户端与 Broker 之间的网络连通性，以及监听地址是否可达。

8. 最后分享几个我实测下来的小技巧

在文章最后，再唠点我自己的实操体会。第一，监控 Rebalance 次数非常重要。Kafka 暴露了很多 JMX 指标，特别是 active-member-count 和 rebalance-rate-per-hour 这类指标。我在项目里会给每分钟 Rebalance 次数超过阈值的消费者组加报警，因为大面积的 Rebalance 往往意味着消费架构出了问题，而不是纯粹的正常扩缩容。

第二，如果你在排查问题时反复看到 unjoined 状态日志，说明消费者在很长一段时间里没能成功加入组。这时不要只盯着消费者日志，去看它是否有足够的线程循环在 join 和 sync 之间跳出；很多时候是 join.group.timeout.ms 设置得太小，导致多实例加入时间差互相踢出，形成了“加入-退出”抖动。适当增大这个超时值能很快缓解。

第三，生产环境里不要轻易改 Topic 分区数来“扩容”。分区数变更一定会引发 Rebalance，而且这种变更在 Kafka 里只能增不能减。如果你只是想让某个消费者处理更多消息，先把分配策略和消费者数量理清楚，再考虑动分区。

每个人的环境不一样，这些经验不一定能 100% 套用，但方向是没错的：理解 Rebalance 的每一步在做什么，再配上合理的监控和参数，绝大多数消费抖动都能控制在一个可接受范围内。希望这篇分享能让你少走几个弯路。