深入解读 RocketMQ 源码（一）：Producer 启动、配置与使用详解

本文链接：https://blog.youkuaiyun.com/qq_39818325/article/details/140162222

深入解读 RocketMQ 源码系列

深入解读 RocketMQ 源码（一）：Producer 启动、配置与使用详解

深入解读 RocketMQ 源码（二）：详解 Message 发送流程

深入解读 RocketMQ 源码（三）：解析 Broker 存储 Message 流程

深入解读 RocketMQ 源码（四）：Consumer 启动流程全解析

深入解读 RocketMQ 源码（五）：详解 Message 消费流程

深入解读 RocketMQ 源码（六）：延迟消息与事务消息的实现原理

深入解读 RocketMQ 源码（七）：Broker 消费队列 ConsumeQueue 的持久化机制

前言

大概一年半前自己写了一篇《云原生》一文搞懂RocketMQ队列概述，这篇对rocketmq的相关概念和使用方法进行了整理概述，就像结尾说的都太局限于表面，简单使用还能将就，但一出现问题自己也很难排查，为了迈向技能的下一个阶段，还得是要读源码，学习大佬们的编码风格和技巧，对于使用mq以及排除问题也会更得心应手。因为最近一年自己的工作充满了波折，让自己没法静下心来学习整理，虽然现在也好不了多少，但可算能回归本心。本章篇幅比较长，将近万字，博主也是自己读源码一步一步跟踪的，所以尽量想描述得通俗易懂一些。

获取源码

首先我们从github上拉取rocketmqd的源码链接到本地，使用idea打开。

源码地址：https://github.com/apache/rocketmq

目前最新版本为：5.2.0

那么我们在idea上切换分支为 release-5.2.0

注：rocketmq5.x与4.x官方改动的东西比较多，尽量使用一直的版本，具体差异可查看官网，这里只对源码逻辑进行分析

总概论

我们知道rocketmq的组成需要四大模块构成，缺一不可

nameserver mq注册中心(状态管理)
broker mq的服务端（核心）
producer 生产者
consumer 消费者

本章我们先从应该大家接触最多的生产者开始学习源码吧。

生产者实例

在idea的rocketmq源码中找到 example 模块，这个模块中都是官方给出的简单案例
然后找到simple 包下面的 Producer类打开
然后在producer类中配置自己的mq的地址，topic以及tag就能成功启动生产者并且发送消息

注意：这里成功启动的前提是必须提前启动了mq的nameserver服务和broker服务才能成功，若没有可不用启动，直接跳过看下面源码

源码

根据上面简单生产者实例可知，生产者端的两大核心就是，启动生产者和发送消息，分别对应下面两行代码。看似简单的两行其实里面的功能逻辑很强大。

```
producer.start();
```
```
producer.send(msg);
```

生产者包含4中状态：

CREATE_JUST 服务刚刚创建，尚未启动

```
RUNNING 服务运行中
```
```
SHUTDOWN_ALREADY 服务已关闭
```
```
START_FAILED 启动出错
```

按照顺序，我们从 生产者的启动开始

public void start() throws MQClientException {
    //A-01:设置生产者组名称
    this.setProducerGroup(withNamespace(this.producerGroup));
    //A-02:生产者服务启动
    this.defaultMQProducerImpl.start();
    //A-03:开启监控和处理同步发送和异步发送操作的守护线程
    if (this.produceAccumulator != null) {
        this.produceAccumulator.start();
    }
    //A-04:开启消息轨迹和发送机制
    if (null != traceDispatcher) {
        try {
            traceDispatcher.start(this.getNamesrvAddr(), this.getAccessChannel());
        } catch (MQClientException e) {
            logger.warn("trace dispatcher start failed ", e);
        }
    }
}

A-01:设置生产者组名称

该方法中顾名思义主要用于设置生产者组的名称
withNamespace（）进入该方法发现，其实对生产者组的名称就行各种非空校验和长度校验，最后根据固定格式拼接名称后返回。（对于开源组件大佬，校验方式也是和我们无异的）

A-02:生产者服务启动

该方法为本次的启动核心方法，我们直接深入了解下其内部实现。

方法逻辑太长我们进行分段拆分来解析

public void start(final boolean startFactory) throws MQClientException {
    switch (this.serviceState) {
            //B-01：初始化状态
        case CREATE_JUST:
            this.serviceState = ServiceState.START_FAILED;
            //B-02：校验
            this.checkConfig();
            //B-03：生产者组名设置
            if (!this.defaultMQProducer.getProducerGroup().equals(MixAll.CLIENT_INNER_PRODUCER_GROUP)) {
                this.defaultMQProducer.changeInstanceNameToPID();
            }
        //...

B-01：初始化状态

因为现在还是正在启动中，所以状态还是默认未启动状态，那么直接进入第一个case逻辑中，进入后里面把状态至为启动失败，我认为这是一种防御性编码，并且防止未成功启动的生产者被重复启动

B-02：该方法再次对生产者组名称进行校验

B-03：判断是否为默认生产者组名称

前面可知我们已经成功设置自定义名称，所以直接进入if中

changeInstanceNameToPID（），该方法就设置实例名称，进入方法可以看到名称的生成规则，this.instanceName = UtilAll.getPid() + "#" + System.nanoTime();
当前运行的虚拟机的名称截取拼接上当前纳米时间戳，保证唯一性

public void start(final boolean startFactory) throws MQClientException {
    /....../
    //B-04：该方法是为了实例化MQClientInstance对象，mq客户端对象实例
    this.mQClientFactory = MQClientManager.getInstance().getOrCreateMQClientInstance(this.defaultMQProducer, rpcHook);
    //B-05：注册生产者
    boolean registerOK = mQClientFactory.registerProducer(this.defaultMQProducer.getProducerGroup(), this);
    /....../

B-04: 该方法是为了实例化MQClientInstance对象，mq客户端对象实例

内部首先生成一个唯一的clientId,其组成包含ip地址与之前生成的实例名称instanceName组成，然后new 了一个MQClientInstance对象并设置对应属性。
将clientId作为key维护到一个Map对象中，private final ConcurrentMap<String/* clientId */, MQClientInstance> factoryTable；

注：MQClientInstance对象，该对象非常重要，因为生产者和消费者都在使用

进入该对象我们可以发现，里面维护了两个Map集合,就是分别存储当前客户端的生产者和消费者的对象数据

private final ConcurrentMap<String, MQProducerInner> producerTable ；
private final ConcurrentMap<String, MQConsumerInner> consumerTable ；

B-05: 该方法就是将当前生产者对象注册到mqClientInstance中的producerTable集合中，并且生产者组名称作为key

public void start(final boolean startFactory) throws MQClientException {
    switch (this.serviceState) {
            /..../
            //B-06： 启动相关核心服务以及开启一系列定时任务
            if (startFactory) {
                mQClientFactory.start();
            }
            /.../

B-06: 启动相关核心服务以及开启一系列定时任务（核心逻辑）

1. 开启请求-响应通道- this.mQClientAPIImpl.start();

2. 开启拉动式服务- this.mQClientAPIImpl.start();

3. 开启负载均衡服务- this.rebalanceService.start();

4. 开启推送服务- this.defaultMQProducer.getDefaultMQProducerImpl().start(false);

这个方法是否有点眼熟,没错这就是我们最开始调用的启动方法A-2,参数传的false,说明上面if代码块中startFactory=false，则不进入B-06的代码块中
并且A-2代码块方法中，因为第一次进入时状态已经从CREATE_JUST变更为START_FAILED，所以也不会再次进入第一个case中
阅读后续代码可知，核心就是调用了 this.mQClientFactory.sendHeartbeatToAllBrokerWithLock(); 向所有Broker服务发送一次心跳（具体后面会详解）

5. 启动各种计划任务- this.startScheduledTask();

所有任务都是使用Executors线程池创建一个单独的的单线程定时任务实现,如下格式

private final ScheduledExecutorService scheduledExecutorService = Executors.newSingleThreadScheduledExecutor(r -> new Thread(r, "MQClientFactoryScheduledThread"));
//....
this.scheduledExecutorService.scheduleAtFixedRate(() -> {
    try {
        //业务逻辑
    } catch (Exception e) {
        log.error("ScheduledTask fetchNameServerAddr exception", e);
    }
}, 1000 * 10, 1000 * 60 * 2, TimeUnit.MILLISECONDS);

a. 启动定时任务获取MQ注册中心nameServer的地址- MQClientInstance.this.mQClientAPIImpl.fetchNameServerAddr();

首次启动延迟时间：2s

定时间隔时间：2m

mQClientAPIImpl对象是否眼熟，没错就是上面B-06-1启动的服务，所以该服务必须在任务执行之前启动，查看源码如此

深入方法中会发现其实就是获取地址处理后存储在一个List集合中，为什么使用集合，我认为如果是集群那就就会有多条地址存在。 private final AtomicReference<List<String>> namesrvAddrList = new AtomicReference<>();
继续深入会发现有Netty的身影，用于服务间远程通信，这里不再研究。
private final ConcurrentMap<String /* addr */, ChannelWrapper> channelTables;
该Map就是用nameserver地址作为key,而value为ChannelWrapper对象，该对象内部就使用了netty框架包中的对象，一个地址对应一个通道封装器。但是该逻辑中并没有使用put操作，只是get获取。

b. 定时从nameServer拉取topic信息到本地存储 - MQClientInstance.this.updateTopicRouteInfoFromNameServer();

首次启动延迟时间：10ms

定时间隔时间：30s

深入方法内部可知，其实就是分别对producerTable与consumerTable的map进行操作遍历，取出对象里面的topic名称，由前面B-04中可知，分别用于存储生产者对象和消费者对象信息
再将topic名称的set集合进行遍历去远程获取nameserver中的topic的路由详细信息，并将信息存储在另一个map对象中。作用： 用于管理和查询主题的路由信息，帮助生产者和消费者确定消息的发送和接收路径。
private final ConcurrentMap<String/* Topic */, TopicRouteData> topicRouteTable = new ConcurrentHashMap<>();

c. 定时清除离线的broker服务并给所有在线的broker发送心跳

MQClientInstance.this.cleanOfflineBroker(); 清除离线的broker

MQClientInstance.this.sendHeartbeatToAllBrokerWithLock(); 给所有的broker发送心跳

首次启动延迟时间：1s

定时间隔时间：30s

清除离线的broker，查看源码可知道，大概意思为首先从private final ConcurrentMap<String, HashMap<Long, String>> brokerAddrTable = new ConcurrentHashMap<>(); map中
- 获取所有broker的地址数据，然后进行遍历，
- 在遍历中取出 topicRouteTable,该map存放的是topic的对象信息
- 再对topic map的values进行遍历，取出topic信息对象中存储的对应broker集合，
- 判断上面的brokerAddrTable中的broker是否在topic维护的broker集合中，没有则清除

d. 定时持久化消费偏移量数据

MQClientInstance.this.persistAllConsumerOffset();

首次启动延迟时间：10s

定时间隔时间：5s

同样的维护了一个Map对象：

private ConcurrentMap<MessageQueue, ControllableOffset> offsetTable;

key则为消息队列对象

深入源码可知，它的消费者持久化实现方式有三种
- lite pull
- mp pull
- mp push

e. 定时调整消费者消息的线程池数量

MQClientInstance.this.adjustThreadPool();

首次启动延迟时间：1m

定时间隔时间：1m

public void start(final boolean startFactory) throws MQClientException {
    switch (this.serviceState) {
            //...
            //B-07：初始化topic路由信息、topic訂閲信息以及topic端点映射信息
            this.initTopicRoute();
            //B-08：开启定时监测broker故障信息任务
            this.mqFaultStrategy.startDetector();
            //...

B-07:初始化topic路由信息、topic訂閲信息以及topic端点映射信息

深入源码可知，首先获取开发者自定义的topic集合，然后分别处理成MQ要求的格式newTopic，然后创建TopicPublishInfo对象，用于存储topic订阅信息newTopic作为key，同样最后放入map中

private final ConcurrentMap<String/* topic */, TopicPublishInfo> topicPublishInfoTable;

查看TopicPublishInfo对象可知，对象里面包含了TopicRouteData对象，我们知道这个对象在上面定时器B-06-5-b中出现过用于存储topic路由信息，并且存储在topicRouteTable map中
所以在本方法中也会通过newTopic去远程从nameserver中拉去TopicRouteData信息，设置到TopicPublishInfo对象中，同样也会对比topic新获取的TopicRouteData与原来定时器存储的topicRouteTable中的是否有变化，有则更新
有变化同时还会更新，上面定时器B-06-5-c中出现的brokerAddrTable map,更新broker的地址信息
同时更新topic端点映射信息-记录每个主题的消息队列与 Broker 之间的映射
private final ConcurrentMap<String/* Topic */, ConcurrentMap<MessageQueue, String/*brokerName*/>> topicEndPointsTable；这是一个嵌套map,因为一个topic可能对应多个broker，那么消息队列也会是对应多个broker, 可以帮助管理和均衡负载，确保消息被分布到不同的 Broker 上。

B-08:开启定时监测broker故障信息任务

深入源码可知，里面维护了一个定时任务，定时监测 Broker 的故障详细信息

首次启动延迟时间：3s

定时间隔时间：3s

同时也维护了一个map,用于存储每一个broker的 故障详细信息，包括故障时间、故障持续时间和可用状态

private final ConcurrentHashMap<String, FaultItem> faultItemTable;

逻辑处理中还会去查询brokerAddrTable中是否还存在当前broker地址信息，不存在则从faultItemTable中移除，然后再去监测broker服务是否可用，若可用则将可用状态 设置为true

public void start(final boolean startFactory) throws MQClientException {
    //...
    //B-09：发送心跳给所有的broker服务
    this.mQClientFactory.sendHeartbeatToAllBrokerWithLock();
    //B-10：开启定时扫描异步请求响应任务
    RequestFutureHolder.getInstance().startScheduledTask(this);

}

B-09:发送心跳给所有的broker服务

发送心跳其实在上面定时器B-06-5-c中已经出现过了，但是没有深入了解，那么定时器中既然已经在发送心跳了，为什么生产者启动最后还要发送呢？

定时任务的作用：定时任务确保客户端在运行过程中定期发送心跳，保持与 Broker 的连接。
启动时的心跳：生产者在启动完成时立即发送心跳，以确保初始化成功、快速检测连接状态并更新路由信息。

同样的心跳机制中也维护了一个map, 用于记录和管理每个 Broker 的心跳信息，private final ConcurrentMap<String, Integer> brokerAddrHeartbeatFingerprintTable;
其中value值称为心跳指纹， MQ通过比较当前心跳指纹和上次记录的指纹，可以判断 Broker 是否正常工作

B-10:开启定时扫描异步请求响应任务

深入源码可知，里面维护了一个定时任务，定时扫描MQ存储的生产者发布的异步请求以及响应的信息，帮助MQ实现异步请求的超时、回调和状态管理，增强系统的异步处理能力。

次启动延迟时间：3s

定时间隔时间：1s

同样的是维护了一个map数据用于存储异步请求以及响应的信息：

private ConcurrentHashMap<String, RequestResponseFuture> requestFutureTable；

那么key为请求时生成的唯一标识，value为RequestResponseFuture对象则记录了请求信息、超时时间、响应信息、回调信息等，mq根据记录的信息做出响应的处理。

源码内部逻辑有一个地方就判断了isTimeout是否请求超时，为true则抛出异常

该map requestFutureTable在本次启动中只是使用，具体在什么地方存储的，应该会在后续的生产者发送消息源码中再次出现，本次启动使用到的requestFutureTable应该都是没数据的。日常开发看似只是简单的调用了发送消息的api方法，而mq内部则做了许多复杂的处理来保证消息的可靠性和高可用性