在 RocketMQ 中，Rebalance（负载均衡） 是指将一个 Topic 下的多个 MessageQueue（消息队列）重新分配给同一个 Consumer Group（消费者组）下的多个 Consumer 实例的过程。

触发 RocketMQ Rebalance 的情况主要可以归结为两大类：消费者（Consumer）数量发生变化 和 主题队列（Topic Queue）数量发生变化。

具体来说，以下几种情况会触发 Rebalance：

一、 消费者（Consumer）发生变化

这是最常见的触发场景。只要同一个消费者组内的实例数量发生增减，就会触发 Rebalance。

1. 新增消费者实例（扩容上线）：
   • 当一个新的消费者程序启动，并加入到某个 Consumer Group 时。为了让新加入的实例分担消费压力，需要重新分配队列。
2. 消费者正常下线（缩容停机）：
   • 当某个消费者实例正常关闭（调用了 shutdown() 方法），它会主动向 Broker 发送取消注册的请求，Broker 收到后会通知组内其他消费者进行 Rebalance，接管退出的消费者原本负责的队列。
3. 消费者异常宕机或网络断开：
   • 消费者实例因为 OOM、进程被强杀或网络故障导致无法与 Broker 保持心跳（RocketMQ 消费者默认每 30 秒向所有 Broker 发送心跳）。如果 Broker 在一定时间（默认 2 分钟）内没有收到心跳，会认为该消费者已掉线，从而通知其他存活的消费者触发 Rebalance。

二、 队列（MessageQueue）或 Broker 发生变化

Topic 的队列是分布在 Broker 上的，如果 Broker 或队列配置发生变化，也会触发重新分配。

1. Broker 宕机或重启：
   • 如果某个 Broker 主节点宕机，该 Broker 上承载的 Topic 队列将不可用。消费者在定时更新路由信息时会发现队列数量减少，从而触发 Rebalance，将宕机 Broker 上的队列从消费列表中剔除。
2. Broker 扩容（新增 Broker）：
   • 如果集群中新增了 Broker 节点，并且为某个现有的 Topic 在新 Broker 上创建了队列，消费者感知到 Topic 队列总数增加后，会触发 Rebalance 来消费新队列中的消息。
3. 动态修改 Topic 的读写队列数量：
   • 管理员通过 RocketMQ 控制台或命令行工具（mqadmin updateTopic）动态增加或减少了某个 Topic 的 readQueueNums（读队列数量）。消费者感知到队列数量变化后，会触发 Rebalance。

三、 底层触发机制（它是如何被触发的？）

从源码和机制角度来看，RocketMQ 的 Rebalance 触发机制分为主动（定时）和被动（通知）两种：

1. 客户端定时触发（主动扫描）：
   • RocketMQ 客户端的 MQClientInstance 中有一个后台线程 RebalanceService。
   • 这个线程默认每隔 20 秒执行一次。它会对比当前最新的 消费者列表 和 队列列表 与上一次是否发生变化，如果发生变化，就会执行 Rebalance 逻辑。
2. Broker 实时通知（被动唤醒）：
   • 当有 Consumer 上线或正常下线时，Broker 会立即感知到。
   • Broker 会主动向该 Consumer Group 内的其他所有在线 Consumer 发送 NOTIFY_CONSUMER_IDS_CHANGED 的请求。
   • 客户端收到这个通知后，会立即唤醒 RebalanceService 线程，立即执行一次 Rebalance，而不需要等待下一个 20 秒的周期。

四、 ⚠️ Rebalance 带来的影响与注意事项

虽然 Rebalance 是实现分布式高可用和动态扩缩容的核心机制，但频繁触发 Rebalance 会带来一些负面影响，开发时需要注意：

1. 消费暂停（STW 效应）：在 Rebalance 期间，消费者可能会短暂停止从某些队列拉取消息，导致消费延迟。
2. 重复消费：对于并发消费模式，Rebalance 时由于前一个消费者可能还没来得及提交消费进度（Offset），新的消费者接管队列后，会从最后一次记录的 Offset 开始拉取，这极易导致消息重复消费。因此，业务消费逻辑必须实现幂等性。
3. 订阅关系必须一致：同一个 Consumer Group 下的所有消费者实例，订阅的 Topic 和 Tag 必须完全一致。如果订阅关系不一致，会导致在 Rebalance 时队列分配混乱，出现部分消息无法消费或消费逻辑错乱的严重 Bug。