RocketMQ你不得不了解的 Rebalance机制源码分析

RocketMQ版本

• version: 5.1.0

RocketMQ中consumer消费模型

在了解RocketMQ的Rebalance机制之前，我们必须先简单了解下rocketmq的消费模型

我们知道在我们创建topic的时候需要指定一个参数就是读队列数

这里假设我们的topic是xiaozoujishu-topic，我们的读队列数 是4个，我们同一gid下的集群消费模式的消费者有两个，那么我们消费者是如何消费消息的呢 首先需要明确的是:

1. 这里我们的消费模式是集群消费
2. queue的负载均衡算法是使用默认的AllocateMessageQueueAveragely（平均分配） 假设我们项目刚开始只有一个消费者，那么我们的消费队列分配就如下:

四个队列分配给一个消费者

此时如果我们再启动一个消费者，那么这时候就会进行Rebalance，然后此时我们的队列分配就变成如下:

所以通过上面的队列分配我就知道Rebalance是个啥了，我们下面对Rebalance进行一些定义

RocketMQ的Rebalance是什么

Rebalance(重新平衡)机制指的是：将一个Topic下的多个队列(queue)，在同一个消费者组(consumer group)(gid)下的多个消费者实例(consumer instance)之间进行重新分配

Rebalance的目的

从上面可以看出Rebalance的本意是把一个topic的queue分配给合适的consumer，本意其实是为了提升消息的并行处理能力

但是Rebalance也带来了一些危害,后面我们会重点分析下

Rebalance的触发原因

我们这里先说结论

1. 订阅Topic的队列数量变化
2. 消费者组信息变化

这里是最深层的原因，就是topic的队列数量、消费组信息 实际我们可以将这些归结为Rebalance的元数据，这些元数据的变更，就会引起clinet的Rebalance

注意RocketMQ的Rebalance是发生在client

这些元数据都在管broker管理 核心就是这三个类

• TopicConfigManager
• SubscriptionGroupManager
• ConsumerManager

只要这个三个类的信息有变化，client就会进行Rebalance。 下面我们可以具体说下什么情况下会让这三个类变化

订阅Topic的队列数量变化

什么情况下订阅Topic的队列数量会变化呢？

1. broker扩容
2. broker缩容
3. broker宕机(本质也是类似缩容)

消费者组信息变化

什么时候消费者组信息会变化呢？

核心就是consumer的上下线，具体细分又可以分为如下原因：

1. 服务日常滚动升级
2. 服务扩容
3. 服务订阅消息发生变化

源码分析

上面大致介绍了Rebalance的触发原因，现在我们结合源码来具体分析下

我们就从consumer的启动开始分析吧

这里我们以最简单的demo为例

java复制代码    DefaultMQPushConsumer consumer = new Default