Elasticsearch 相关度评分：从 BM25 到 Function Score 实战

RocketMQ 的重平衡（Rebalance）机制决定了消费者组内的队列分配方式，也是跨环境同名消费者组冲突的根本原因。

一、什么是 Rebalance

RocketMQ 中，一个 Topic 的消息被分散在多个 MessageQueue 中。消费者组（Consumer Group）内的多个消费者实例，需要协商好”谁消费哪几个队列”——这个协商过程就是 Rebalance（重平衡）。

触发 Rebalance 的时机：

• 消费者实例上线/下线
• Topic 的队列数量变化
• 定时触发（默认每 20 秒执行一次）

---

二、Rebalance 的核心流程

graph TD
    A[消费者启动] --> B[向 Broker 注册，加入消费者组]
    B --> C[从 NameServer 拉取 Topic 路由信息]
    C --> D[从 Broker 拉取同组所有消费者列表]
    D --> E[对消费者列表和队列列表排序]
    E --> F[按分配策略计算自己应消费的队列]
    F --> G[与上次分配对比，启动/停止对应队列的消费]

关键点：RocketMQ 的 Rebalance 是客户端自治的，每个消费者实例独立计算自己应该消费哪些队列——只要输入一致（消费者列表 + 队列列表），各实例计算出的结果就能互不重叠。

---

三、分配策略

RocketMQ 提供多种分配策略，默认是 AllocateMessageQueueAveragely（平均分配）：

假设有 8 个 MessageQueue，3 个消费者实例 [C0, C1, C2]：

实例	分配的队列
C0	Q0, Q1, Q2
C1	Q3, Q4, Q5
C2	Q6, Q7

其他策略：

• AllocateMessageQueueAveragelyByCircle：轮询分配，比平均分配更均匀
• AllocateMessageQueueByMachineRoom：机房就近分配，用于多数据中心场景
• AllocateMessageQueueConsistentHash：一致性哈希，减少 Rebalance 时的队列迁移

---

四、根本问题：不同环境、不同 Topic 使用同一个消费者组名

这是我在实际开发中踩过的坑，也是很多团队容易忽视的配置问题。

场景还原

• 测试环境和生产环境连接的是同一套 RocketMQ 集群（资源共用）
• 测试 Topic：order-test，生产 Topic：order-prod
• 两个环境的消费者都使用了同一个 Group Name：order-consumer-group

出现的问题

由于消费者组名相同，测试环境的消费者实例会被 Broker 识别为同一个消费者组的成员。

Rebalance 触发时，Broker 上的消费者列表变成：

order-consumer-group 成员：
  - 生产实例 prod-pod-1 （订阅 order-prod）
  - 生产实例 prod-pod-2 （订阅 order-prod）
  - 测试实例 test-pod-1 （订阅 order-test）

RocketMQ 客户端在计算分配时，会把所有成员的订阅关系合并，当发现同一组内有人订阅了不同的 Topic，会产生以下副作用：

1. 消费偏移量被污染：测试环境消费了部分生产队列的消息，导致 offset 推进，生产消费者拉不到这些消息。
2. 订阅关系冲突告警：Broker 会打印 subscription data is not same 的警告日志。
3. 消息丢失：极端情况下，生产消息被测试环境消费者消费后丢弃（因为测试环境通常不做完整业务处理）。

为什么看起来”偶尔才出问题”

因为 Rebalance 是周期触发的，且各实例的触发时机不同步。测试环境消费者偶尔上线、下线，恰好触发了生产消费者组的 Rebalance，才会暴露问题。

---

五、解决方案

方案一：消费者组名加环境前缀（推荐）

最简单直接，修改成本最低：

// 测试环境
consumer.setConsumerGroup("test_order-consumer-group");

// 生产环境
consumer.setConsumerGroup("prod_order-consumer-group");

或者读取配置文件中的环境变量：

String env = System.getProperty("spring.profiles.active", "dev");
consumer.setConsumerGroup(env + "_order-consumer-group");

方案二：环境隔离，使用独立 RocketMQ 集群

彻底解决方案，但成本较高。测试环境和生产环境各自有独立的 NameServer 和 Broker，从根本上隔离。

方案三：Topic 名也加环境前缀，消费者组名同步隔离

测试：Topic = order-test, Group = order-consumer-group-test
生产：Topic = order-prod, Group = order-consumer-group-prod

这样即使连同一个集群，组名不同，Rebalance 也互不干扰。

---

六、Rebalance 的已知问题

重复消费

Rebalance 期间，队列的归属发生变化，新分配队列的消费者会从 Broker 上的 offset 重新拉取。如果上一个消费者拉取了消息但还没提交 offset 就被 Rebalance 了，新消费者会重新消费这批消息。

结论：RocketMQ 的消费语义是 at-least-once，必须在业务层实现幂等。

Rebalance 导致的短暂消费停滞

Rebalance 执行期间，消费者会暂停拉取，直到新分配完成。默认 20 秒的 Rebalance 间隔意味着：如果一个消费者实例频繁重启，会导致消费有规律性的短暂停顿。

---

七、总结

问题	原因	解决方案
跨环境消费冲突	不同环境使用同一 Group Name	Group Name 加环境前缀
重复消费	Rebalance 期间 offset 未提交	业务层实现幂等
消费停滞	频繁 Rebalance	避免频繁重启，合理设置心跳超时

Rebalance 机制本身设计是合理的——客户端自治、无需协调者、一致性哈希可以减少迁移量。问题往往来自配置疏忽，尤其是在多环境共用集群时，Group Name 的隔离是最容易被忽略的一环。