RocketMQ的Rebalance详解

负载均衡

RocketMQ的消费负载是通过queue来对消息进行分片，然后consumer消费自己对应的queue来实现。我们以如下场景为例：

topicA有两个队列：queue1和queue2。
消费组groupA有一台机器：consumer1

queue分配如下图所示，由于只有一台消费者机器，所以分布在queue1和queue2的消息都被consumer1消费掉。

如果这个时候开发人员收到消息积压告警，说明一个consumer已经无法及时处理所有消息了，对于这种情况通常会选择对消费集群进行扩容。于是新增了一台机器consumer2来协助处理积压的消息。情况变成下图所示：

Rebalance

这里需要大家思考一下，rocket是如何把queue2从consumer1调整到consumer2的？这里只是一个简单的实例，真实环境下可能是十几个queue对应十几个consumer。这样的对应关系更复杂，如果新增或删除一些consumer节点都需要去重新调整消费关系。

其实rocket是通过Rebalance机制来完成queue和consumer关系的协调的。Rebalance的意思就是再平衡。Relanace机制是如何实现消费关系再平衡呢？其内部的运转机制又是如何？我们接下来一探究竟。

rocket的Rebalance是在消费者侧实现的，这里大家不禁会疑惑，消费者都是相互独立的，如何能一同协调消费关系？不会出现脑裂的情况吗？

rocket是这么实现Rebalance：

触发时机
- 在consumer启动或者停止的时候，此时consumer的数量发生变动，消费者会主动触发一次Rebalance。
- 收到broker发送的rebalance通知时。
- 消费者启动后会通过一个异步线程每隔20s触发一次Rebalance。
向服务端获取topicA最新的queue列表和consuemr节点列表，根据这些最新的信息重新分配消费关系
分配策略
- rocket提供多个分配策略，消费机器不同但是内部代码是相同的，所以会选择相同的分配策略，通过相同的策略来保证不同的消费者执行Rebalance后得到相同的分配结果。这里大家可能会提问是否会存在一些切换的间隙，分配不一致的情况呢？的确存在，这时可能会导致不同消费者重复消费同一个queue的消息，但是这种状态是短暂的，而且可以通过幂等校验来规避业务上的影响。通过多次的Rebalance最终会达到稳定。稳定会持续到下一次平衡关系的破坏。
消费关系分配完成后客户端会对比之前的消费关系是否发生改变，如果有新增的queue则将其加入到pullRequest请求队列中，如果之前消费的某个queue被移除，则将其标记为drop，后续流程通过这个标记会将其从pullRequest队列中剔除

Rebalance流程图

顺序消息的Rebalance

顺序消息在Rebalance过程中是如何做到保证严格的顺序的呢？其实也很简单粗暴，直接向broker发起queue上锁请求，上锁成功之后才能完成关系调整，代码如下：

if (isOrder && !this.lock(mq)) {log.warn("doRebalance, {}, add a new mq failed, {}, because lock failed", consumerGroup, mq);continue;
}

总结

以上就是对Rebalance流程的介绍，rocket通过客户端实现来降低设计难度，消费端通过幂等来规避短暂Rebalance所带来的消息重复的影响。