源码分析RocketMQ消息消费机制----消费端消息负载均衡机制与重新分布

最后

小编精心为大家准备了一手资料

以上Java高级架构资料、源码、笔记、视频。Dubbo、Redis、设计模式、Netty、zookeeper、Spring cloud、分布式、高并发等架构技术

【附】架构书籍

1. BAT面试的20道高频数据库问题解析
2. Java面试宝典
3. Netty实战
4. 算法

BATJ面试要点及Java架构师进阶资料

本文已被CODING开源项目：【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码】收录

需要这份系统化的资料的朋友，可以点击这里获取

RebalanceImpl.rebalanceByTopic

RebalanceImpl.updateProcessQueueTableInRebalance

RebalanceImpl.dispatchPullRequest

DefaultMQPushConsumerImpl.executePullRequestImmediately

PullMessageService.executePullRequestImmediately

从上面可以直观的看出，向 PullMesssageService 的 LinkedBlockingQueue pullRequestQueue 添加 PullRequest的是 RebalanceService.run 方法，就是向 PullMessageService 中放入 PullRequest,才会驱动 PullMessageSerivce run方法的运行，如果 pullRequestQueue 中没有元素，PullMessageService 线程将被阻塞。

那么RebalanceService是何许人也，让我们一起来揭开其神秘面纱。

2、消息消费负载机制分析

============

2.1 RebalanceService 线程

---

从上面可以看出，MQClientInstance 持有一个 RebalanceService 线程并启动它。RebalanceService 线程的 run 方法比较简单，就是直接调用 mqClientFactory.doRebalance。

下面重点分步骤来详细探究 MQClientInstance.doRebalance 方法的执行流程。

2.1.1 MQClientInstance.doRebalance

循环遍历每个消费组获取 MQConsumeInner 对象（其实就是 DefaultMQPushConsumerImpl 或 DefaultMQPullConsumerImpl 对象），并执行其 doRebalance 方法。

2.1.2 DefaultMQPushConsumerImpl.doRebalance

RebalanceImpl doRebalance

到这里，经过层层对象委托，终于进入到实现消息负载分发的核心地带了，RebalanceImpl 类，我们应该停下脚步，先重点认识一下RebalanceImpl类。

3、RebalanceImpl 类初探

===================

我们先来看看其核心属性：

• ConcurrentMap<MessageQueue, ProcessQueue> processQueueTable

消息处理队列。

• ConcurrentMap<String, Set topicSubscribeInfoTable

topic 的队列信息。

• ConcurrentMap<String, SubscriptionData> subscriptionInner

订阅信息。

• String consumerGroup

消费组名称。

• MessageModel messageModel

消费模式。

• AllocateMessageQueueStrategy allocateMessageQueueStrategy

队列分配算法。

• MQClientInstance mqClientFactory

MQ 客户端实例。

下面还是从doRebalance方法入手：

1、根据 topic 来进行负载。

2、移除 MessageQueue，如果 MesageQueue 的 topic 不在订阅的主题中，接下来重点关注 rebalanceByTopic 方法。

RebalanceImpl rebalanceByTopic详解:

part1:根据消息消费模式（集群还是广播）我们先重点看集群模式。

part2: 获取主题的消息消费队列、主题与该消费组的消费者id列表,任意一个为空，则退出方法的执行。

part3: 主要是对主题的消息队列排序、消费者ID进行排序，然后利用分配算法，计算当前消费者ID(mqClient.clientId) 分配出需要拉取的消息队列。

具体的消息消费队列分配算法参考：AllocateMessageQueueStrategy的实现类，具体算法实现就不细化研究了。

在这里举一个最简单的队列分配机制，，比如一个topic 有8个消息队列(q1,q2,q3,q4,q5,q6,q7,q8) ，比如有三个消费者 c1,c2,c3

一种队列负载算法： q1,q4,q7 分给c1,q2,q5,q8 c2,q3,q5 给 c3。下文会专题研究一下负载算法。

part4: 更新主题的消息消费处理队列，并返回消息队列负载是否改变。

遍历消息队列-处理队列缓存，只处理 mq 的主题与该主题相关的 ProcessQueue, 如果 mq 不在当期主题的处理范围内（由于消息队列数量变化等原因，消费者的消费队列发生了变化，该消息队列已经分配给别的消费者去消费了），首先设置该消息队列为丢弃 (dropped 为 voliate 修饰)，可以及时的阻止继续向 ProceeQueue 中拉取数据，然后执行removeUnecessaryMessageQueue(mq,pq) 来判断是否需要移除。

既然我们都是从Push进入的，本文以Push模式展开(同时我们也可以先思考思考push,pull差别)，移步到RebalancePushImpl。

目前只看非顺序消息，逻辑就比较简单了，丢弃之前，先将 MessageQueue 消息消费进度 持久化，然后丢弃，重新被其他消费者加载。顺序消息将会本系列的后续文章中详细介绍。

接下来处理 MessageQueue 的 ProcessQueue,也就是在 ProcessQueueTable 中没有 mq 的处理队列（因为重新负载后，可能会分配一些新的队列）。

主要就是在内存中移除 MessageQueue 的 offerset, 然后计算下一个拉取偏移量，然后每一个MessageQueue创建一个拉取任务(PullRequest)。

RebalancePushImpl

PullMessageService

最近我根据上述的技术体系图搜集了几十套腾讯、头条、阿里、美团等公司21年的面试题，把技术点整理成了视频（实际上比预期多花了不少精力），包含知识脉络 + 诸多细节，由于篇幅有限，这里以图片的形式给大家展示一部分

本文已被CODING开源项目：【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码】收录

需要这份系统化的资料的朋友，可以点击这里获取

，由于篇幅有限，这里以图片的形式给大家展示一部分

[外链图片转存中…(img-o2yyolQz-1715692007047)]

本文已被CODING开源项目：【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码】收录

需要这份系统化的资料的朋友，可以点击这里获取