有次上线监控告警突然炸了，Kafka 订单 Topic 消息积压量突破 10 万条，下游支付服务拿不到数据，部分用户付款后一直显示处理中。
紧急登录集群排查，发现消费者组明明有 3 个节点，却只有 1 个在正常消费，原来 10 分钟前触发了 Rebalance，另外两个节点还卡在分区重新分配的状态，导致消费能力直接砍半。
所以我的经验是：Kafka出现消息积压、重复、丢失这类问题，直接看是否有Rebalance，能解决大部分问题。
什么时候会触发 Rebalance？
Rebalance 本质是消费者组内分区与消费者的重新分配，只有当消费者、分区的对应关系被打破时才会触发，下边咱们看看几种比较常见的场景：
1. 消费者数量变了（最频繁）
扩容触发：业务高峰时加了消费者节点，比如 3 个分区原本 2 个消费者承担，新增 1 个后，需要重新分配成 1 个消费者对应 1 个分区；
下线触发：消费者节点宕机、网络断连，或进程被误杀，比如 3 个消费者少了 1 个，剩下 2 个要接手它的分区，必然触发 Rebalance。
之前我们的日志服务就踩过坑：K8s 节点资源不足，导致消费者 Pod 频繁重启，每重启一次就触发一次 Rebalance，消息积压越来越严重。
2. Topic 分区数加了
Kafka 不支持减少分区，但新增分区时，已存在的消费者组不会自动感知新分区，必须通过 Rebalance，才能把新分区分配给组内消费者。
比如给order-topic从 5 个分区扩到 8 个，原本的消费者组只会消费旧的 5 个分区，直到触发 Rebalance 后，才会接手新增的 3 个分区。
3. 订阅的 Topic 变了
消费者组通过subscribe()订阅 Topic 时，若修改订阅列表（比如从只订阅order-topic，改成同时订阅order-topic和pay-topic），会触发 Rebalance，重新分配所有订阅 Topic 的分区。
4. 心跳或消费超时（隐性坑）
消费者靠心跳向 Coordinator（协调者）证明自己活着，这两个超时参数设不好，很容易触发误判式 Rebalance：
心跳超时：消费者每 3 秒（默认heartbeat.interval.ms）发一次心跳，超过 45 秒（默认session.timeout.ms）没发，就被判定死亡；
消费超时：处理单批消息超过 5 分钟（默认max.poll.interval.ms），哪怕心跳正常，也会被强制踢出组，触发 Rebalance。
我们之前处理大订单消息时，单条消息处理要 6 分钟，直接触发消费超时，导致 Rebalance 频繁发生。
Rebalance 引起哪些问题
Rebalance 不是瞬间完成的，整个过程要经历注销旧分区→选举 Leader→分配新分区→消费者初始化，期间对业务的影响比你想的大。
1. 消费暂停，消息积压
Rebalance 期间，所有消费者都会暂停消费，等待新的分区分配。如果消费者组规模大（比如 100 个消费者、1000 个分区），Rebalance 可能持续几十秒，这段时间 Topic 消息只会堆积，下游服务拿不到数据。
所以在有消息积压的情况，优先看看是否有 Rebalance 的情况。
2. 消息重复和消息丢失
Rebalance 后，消费者重新拿到分区时，消费进度可能倒退：若没及时提交 offset（不管自动还是手动），会从最后一次提交的 offset 开始消费，中间没提交的消息要么重复处理，要么直接跳过，也就是消息重复消费和消息丢失的原因。
极端情况（比如 Coordinator 宕机），offset 存储的分区发生主从切换，可能导致 offset 数据错乱，进度直接回到几天前。
3. 资源浪费，负载不均
Rebalance 要靠 Coordinator 协调，频繁触发会占用 Kafka 集群的 CPU 和网络资源；而且 Kafka 默认的分区分配策略（Range 或 RoundRobin），很容易导致负载不均。
比如 5 个分区分配给 2 个消费者，可能出现 3 个分区 vs 2 个分区的情况，其中一个消费者压力翻倍，处理速度变慢，又会触发新的 Rebalance，陷入恶性循环。
什么情况下会丢数据
Rebalance 本身不会直接丢数据，但结合offset 提交和处理逻辑，很容易出现消息漏消费。
1.自动提交 offset + 消费没完成
Kafka 默认自动提交 offset，提交时机是 poll 到消息后，等 5 秒（默认auto.commit.interval.ms）自动提交。如果刚提交完 offset，消息还没处理完就触发 Rebalance，新消费者会从已提交的 offset 之后 开始消费，中间没处理的消息就丢了。
举个例子：
消费者 A poll 到 offset 100-200 的消息，5 秒后自动提交 offset 200；
处理到 150 条时，节点突然宕机，触发 Rebalance；
新消费者 B 从 offset 200 开始消费，offset 150-199 的消息直接丢失。
2. 手动提交 offset 时机错了
手动提交时，如果把提交 offset 放在处理消息之前，也会丢数据。
错误逻辑：先提交 offset → 再处理消息；
风险：提交后、处理前触发 Rebalance，新消费者会跳过已提交的消息，导致未处理的消息丢失。
正确的做法应该是先处理消息→再提交 offset，确保消息处理完才更新进度。
什么情况下会重复消费？
相比丢数据，kafka Rebalance 导致的重复消费更普遍，核心原因都是 offset 提交滞后于消息处理。
1. 手动提交时，Rebalance 打断了提交
开启手动提交后，若在处理完消息→提交 offset 的间隙触发 Rebalance，offset 没提交成功，新消费者会从上次提交的位置重新消费。
消费者 A 处理完 offset 100-200 的消息，准备提交时，因心跳超时被踢出组；
新消费者 B 从 offset 100 开始消费，导致 100-200 的消息被重复处理。
2. 消费超时被踢，消息还在处理
处理消息耗时超过max.poll.interval.ms，消费者被判定死亡，但实际还在处理消息。
消费者 A 处理大消息用了 6 分钟，超过默认 5 分钟的超时时间，被踢出组；
新消费者 B 接手分区，从上次提交的 offset 开始消费；
消费者 A 后来处理完消息，想提交 offset 却发现自己已被踢出，提交失败，导致消息重复。
3. offset 找不到，回退到最早
如果消费者组的auto.offset.reset设为earliest（默认是latest），Rebalance 后找不到已提交的 offset（比如 offset 数据损坏），会从 Topic 最早的消息开始消费，导致历史消息重复。
如何优化 Rebalance
Rebalance 这种情况是无法完全避免，不过我们可以来优化，能把影响降到最低。
1. 避免频繁触发 Rebalance
调优超时参数：根据消息处理耗时，把max.poll.interval.ms设大（比如大消息设为 10 分钟），session.timeout.ms设为 60-120 秒，避免误判死亡；
保证消费者稳定：用监控盯紧消费者节点的 CPU、内存，避免 K8s Pod 频繁重启，或服务器宕机。
2. 安全处理 offset 提交
优先手动提交，关闭自动提交（enable.auto.commit=false），在消息处理完成后再调用commitSync()提交；
必要时用事务，如果业务不允许重复消费，结合 Kafka 事务，确保消息处理 和 offset 提交原子性。
3. 优化分区分配
选粘性分配策略：把partition.assignment.strategy设为StickyAssignor，Rebalance 时尽量保留原有分配，减少分区变动。
4. 优化消费逻辑
做好幂等性：比如用订单 ID 作为唯一键，即使重复消费，也不会导致业务逻辑出错（比如重复扣钱、重复生成订单）。
写在最后
Rebalance 是面试的时候常爱问的场景题，它是 Kafka 消费者组的双刃剑，用好能均衡负载，用不好就会引发故障，最后我总结下：
触发 Rebalance 主要是消费者或分区变了或超时了；
丢数据和重复消费，本质是 offset 提交和 Rebalance 时机没配合好；
优化超时参数、手动提交 offset、做好幂等性，是减少影响的关键。
看完等于学会，点个赞吧！！！
