RocketMQ的Producer源码分析

RocketMQ的Producer源码分析

这一节我们从RocketMQ的Producer的启动流程开始探究Producer的启动以及生产者消息的发送。

Producer的启动流程

Producer的启动主要会经过以下步骤：

1. 校验producerGroup，包括非空校验、字符长度校验、合法字符校验、非系统内置名称校验等
2. 使用PID设置实例名称，如果不是内置的producerGroup
3. 创建MQClientInstance，会优先从缓存中获取，如果缓存中有则直接返回，这也意味着相同的clientId会共享MQClientInstance
4. 向MQClientInstance注册producer，相同的producerGroup共享DefaultMQProducerImpl
5. 启动MQClientInstance，这一步在初始化过程中只会被调用一次，也是Producer启动的关键
   • 如果没有指定NameServer地址，则会尝试从配置中心拉取，我们通常会在启动Producer时指定，没有指定的场景通常用在多集群的业务中，方便统一进行管理
   • 启动MQClientAPIImpl，这里会完成NettyClient的初始化，为网络通信做准备
   • 开启一系列的定时任务
     • 如果没有指定NameServer地址，则定期从配置中心拉取
     • 定期更新Topic的路由信息，这里会随机选择一个NameServer进行通信，获取topic对应的路由信息并更新到本地的内存中
     • 定期给所有的Broker发送心跳
     • 定期持久化消费进度以及定期调整消费者线程大小（这两个是给Consumer使用的）
   • 初始化内置的Producer
   • 由于Producer和Consumer共用了MQClientInstance，剩下的步骤实际上是Consumer初始化才用到的，这里就不展开了
6. 设置producer状态为RUNNING，刚启动时producer状态是START_FAILED
7. 向所有的Broker发送心跳，因为需要和所有的Broker通信
8. 启动定时任务，处理过期的请求。这一步主要针对request方法，producer.request()是RocketMQ在4.6版本才开始支持的新特性，该功能目前应用较少，这里就不过多赘述

Producer的发送流程

Producer的主要发送流程如下：

1. producer.send最终实际上会委托给DefaultMQProducerImpl的sendDefaultImpl方法，下面来重点分析sendDefaultImpl方法

2. 首先需要确保serviceState是RUNNING状态，一般producer初始化成功之后就会将serviceState设置为RUNNING状态

3. 对消息进行一系列的校验

   （1）校验Topic是否非法，包括是否非空、是否超长、是否包含非法字符

   （2）校验Topic是否是系统保留的主题，如“TBW102”、“SCHEDULE_TOPIC_XXXX”等

   （3）校验消息体，包括是否非空、是否超长（默认最大4M）

4. 获取topic的路由信息，优先会从本地缓存中获取，如果本地没有，则会尝试从NameServer获取，然后更新到本地缓存

5. 根据路由信息从Queue列表中选择一个Queue，这里会两种负载均衡策略：轮询和可用性容错轮询

   （1）先说一下轮询策略，Producer为每个Topic维护了一个全局的计数器，没发送一条消息则+1；每次发送消息需要选择Queue时，用计数器的当前值%Queue大小，得到的index所在的Queue就是本次选中的Queue

   public MessageQueue selectOneMessageQueue(final String lastBrokerName) {
       if (lastBrokerName == null) {
           return selectOneMessageQueue();
       } else {
           // 上一次发送失败的Broker本次不会被选中
           for (int i = 0; i < this.messageQueueList.size(); i++) {
               int index = this.sendWhichQueue.incrementAndGet();
               int pos = Math.abs(index) % this.messageQueueList.size();
               if (pos < 0)
                   pos = 0;
               MessageQueue mq = this.messageQueueList.get(pos);
               if (!mq.getBrokerName().equals(lastBrokerName)) {
                   return mq;
               }
           }
           return selectOneMessageQueue();
       }
   }
   
   public MessageQueue selectOneMessageQueue() {
       // 每发送一次全局计数器+1
       int index = this.sendWhichQueue.incrementAndGet();
       int pos = Math.abs(index) % this.messageQueueList.size();
       if (pos < 0)
         pos = 0;
       return this.messageQueueList.get(pos);
   }
   

   （2）可用性容错轮询在轮询的基础上增加了延时容错机制：尽管上一次选择的Broker发送失败了，重试时依然可以选到上次失败的Broker；如果没有可用的Broker，则选择一个相对较好的；如果根据前边的逻辑依然找不到可用的MessageQueue，则跟未开启延时容错功能一样，直接顺序选择下一个

   public MessageQueue selectOneMessageQueue(final TopicPublishInfo tpInfo, final String lastBrokerName) {
     	// 如果开启了延迟容错功能
       if (this.sendLatencyFaultEnable) {
           try {
               int index = tpInfo.getSendWhichQueue().incrementAndGet();
               for (int i = 0; i < tpInfo.getMessageQueueList().size(); i++) {
                   int pos = Math.abs(index++) % tpInfo.getMessageQueueList().size();
                   if (pos < 0)
                       pos = 0;
                   MessageQueue mq = tpInfo.getMessageQueueList().get(pos);
                 	// 如果该Broker当前是可用的
                   if (latencyFaultTolerance.isAvailable(mq.getBrokerName()))
                       return mq;
               }
   
             	// 如果没有可用的Broker，选择一个相对较好的
               final String notBestBroker = latencyFaultTolerance.pickOneAtLeast();
               int writeQueueNums = tpInfo.getQueueIdByBroker(notBestBroker);
             	// 保证选中的Broker是可写的
               if (writeQueueNums > 0) {
                   final MessageQueue mq = tpInfo.selectOneMessageQueue();
                   if (notBestBroker != null) {
                       mq.setBrokerName(notBestBroker);
                       mq.setQueueId(tpInfo.getSendWhichQueue().incrementAndGet() % writeQueueNums);
                   }
                   return mq;
               } else {
                   latencyFaultTolerance.remove(notBestBroker);
               }
           } catch (Exception e) {
               log.error("Error occurred when selecting message queue", e);
           }
   
         	// 如果上边都没有找到，则跟未开启延时容错功能一样，直接顺序选择下一个
           return tpInfo.selectOneMessageQueue();
       }
   
     	// 未开启延时容错功能一样，直接顺序选择下一个
       return tpInfo.selectOneMessageQueue(lastBrokerName);
   }
   

   （3）RockerMQ Producer的延迟策略：在消息发送（无论成功失败与否）之后，都会把消息发送耗时和发送状态以BrokerName的维度更新到MQFaultStrategy中，MQFaultStrategy会根据消息发送耗时和发送状态更新该Broker的不可用时间，MQFaultStrategy维护了一个Broker延时列表，对应关系如下：

   private long[] latencyMax = {50L, 100L, 550L, 1000L, 2000L, 3000L, 15000L};
   private long[] notAvailableDuration = {0L, 0L, 30000L, 60000L, 120000L, 180000L, 600000L};
   

   • latencyMax和notAvailableDuration这两个数组按照index一一对应
   • 当发送耗时小于550ms时，Broker不可用时长为0ms，以此类推
   • 当发送消息失败时，该Broker的发送耗时为30000ms，意味着该Broker在10分钟内为不可用状态

6. 调用sendKernelImpl发送消息

   （1）根据BrokerName从本地路由信息中获取Broker地址，如果没有获取到，则尝试从NameServer，然后更新到本地缓存

   （2）切换到VIPChannel，端口号为Broker的默认端口-2。Broker启动时会开启2个端口接收客户端的数据，其中一个端口只接收Producer的消息，不接收Consumer的拉取请求，称为VIPChannel

   （3）为Message生成UniqID，即客户端的MsgId，批量消息不会设置

   （4）如果消息大小超过4K，则会尝试压缩消息

   （5）如果有CheckForbidden的钩子，则执行checkForbidden

   （6）设置发送消息请求头的一系列属性

   （7）调用RemotingClient发送网络请求，如果是异步发送方式，会传入SendCallback函数

   （8）如果有SendMessage的钩子，则执行sendMessageAfter

   （9）如果是异步发送且设置了回调方法，则发送完成后执行回调方法（可能是成功，也可能是失败）

7. 无论消息发送成功失败与否，都会更新容错信息

8. 如果没有可以重试（sendOneway模式不可重试）且没有到达最大重试次数，则会触发重试逻辑