从源码看RocketMQ的消费端负载均衡和Rebalance机制

Consumer的负载均衡

RocketMQ在消费端的负载均衡如下图所示，各个partition（partition是kafka的概念，这里应该叫Queue）均匀分布在各个consumer上，如下图所示：

所有consumer依次消费每一个partition，如果partition数量不是consumer的整数倍，则排在前面的consumer会消费更多的partition，下面可以看看consumer的实现。

Rebalance的实现

RocketMQ的consumer负载均衡依赖于RebalanceImpl类，以push的方式为例，在DefaultMQPushConsumerImpl为例，其中包含RebalancePushImpl：

RebalanceImpl负责消费端的负载均衡，其中的doRebalance方法：

我们再进入到rebalanceImpl的doRebalance方法，其中调用了rebalanceByTopic，我们看看rebalanceByTopic中的逻辑：

可以看到，其主体逻辑比较简单：

• 先获取topic下的MessageQueue，一个MessageQueue实际上就是一个partition
• 然后获取当前topic和group的client id，即当前group中消费此topic的客户端
• 随后对partition和client id做排序
• 然后调用strategy获取当前客户端需要消费的partition
• 最后更新订阅

因此，负载均衡的主体算法在AllocateMessageQueueStrategy中实现，通过DefaultMQPushConsumer的默认构造器我们可以看到，默认使用的AllocateMessageQueueStrategy是AllocateMessageQueueAveragely实现类：

找到具体的实现类后，我们可以看到默认使用的负载均衡算法：

公式写的非常绕，代几个数进去算一下就知道，默认情况下，rocketmq使用的是连续分配的方式，示意图如下：

AllocateMessageQueueStrategy提供了多个实现：

• AllocateMessageQueueAveragely是前面讲的默认方式
• AllocateMessageQueueAveragelyByCircle则是本文最前面的示意图，每个消费者依次消费一个partition
• AllocateMessageQueueConsistentHash使用的是一致性hash算法
• AllocateMachineRoomNearby是通过就近元则，离的近的消费
• AllocateMessageQueueByConfig是通过配置的方式

在不同的情况下，我们可以选择使用不同的负载均衡实现方式。

对于特定场景，甚至可以自己实现负载均衡策略，比如我们的应用需要消费非常多个topic，而每个topic的partition不一定刚才都是机器 数量的整数倍，这个时候，按照rocketmq提供的负载均衡策略，排在前面的consumer消费的partition数量会多于后面的consumer，当topic非常多时，这就导致排在前面的consumer消费的partition比后面的consumer要多很多，造成集群中不同机器的水位相差非常大，这种场景下就知道自己实现负载均衡策略

何时重新Rebalace

这里先要介绍一个类MQClientInstance，此类在DefaultMQPushConsumerImpl的start方法中有如下代码：

这里的mQClientFactory的实现类实际上就是一个MQClientInstance，进入到MQClientInstance类的构造器中，我们可以看到它创建了一个RebalanceService对象，代码如下：

我们一级级的看下去，在RebalanceService的run方法中，可以看到，默认每20s调一次doRebalance:

而在父类ServiceThread中，我们可以看到run方法的调用方式，实际上是创建了一个线程：

因此，当一个consumer出现宕机后，默认最多20s，其它机器将重新消费已宕机的机器消费的partition，同样当有新的consumer连接上后，20s内也会完成rebalance使得新的consumer有机会消费partition

原文：从源码看RocketMQ的消费端负载均衡和Rebalance机制