RocketMQ(八):消息发送

匠心零度 转载请注明原创出处,谢谢!

RocketMQ网络部署图

  • NameServer:在系统中是做命名服务,更新和发现 broker服务。
  • Broker-Master:broker 消息主机服务器。
  • Broker-Slave: broker 消息从机服务器。
  • Producer: 消息生产者。
  • Consumer: 消息消费者。

说明: rocketmq系列都将会以rocketmq-4.1.0-incubating进行介绍。

在阅读源码时做了一定的注释,公众号【匠心零度】回复:rocketmq,可获得基于rocketmq4.1.0加详细中文代码注释 。欢迎大家 star、fork !

厮大说过消息中间件的本质消息中间件大道至简:一发一存一消费 ,今天主要来讨论下,就是RocketMQ网络部署图中用颜色标记的部分。

往期rocketmq系列文章

  • RocketMQ部分数据消费不了问题排查
  • 让你rocketmq用得比预期要好的 1 种方法
  • RocketMQ(一):源码调试
  • rocketmq番外篇(一):开发命令行
  • RocketMQ(六):namesrv再探
  • RocketMQ(五):namesrv初探
  • CRC 校验
  • RocketMQ(二):RPC通讯
  • RocketMQ解惑篇
  • RocketMQ快速入门
  • MQ 应用场景
  • RocketMQ集群部署配置
  • 阿里RocketMQ

消息发送概述

上面的图大概就是producer发送message到broker的核心逻辑了。

问题思考:

把broker相关信息缓存到客户端减少了与namesrv的交互,但是也降低了broker变化的实时性了,如何忽然有一台broker不可用了会怎么样呢?(后续看看rocketmq的处理),为什么producer发送会那么快呢?本质是由于netty的writeAndFlush?producer如何做到异步发送?同步发送?oneway发送的呢?如果发送失败会怎么处理呢?

消息发送一般流程分析

由于发送还涉及到定时发送,顺序发送,批量发送等情况,本篇考虑到篇幅问题就是一般的发送逻辑讲解,后面继续分享其他情况。

阅读本篇前应该重点阅读下:RocketMQ(二):RPC通讯。

如何在本地调试之前文章也分享过了,在此就不提了,发送的逻辑相对于存储以及消费来说是最简单的(直接根据一条线不断的跟下去基本就差不多了),而存储最复杂,其次消费(这些过程可能一条线不好找,后续分享)。

同步发送写法

备注: 可以参考RocketMQ快速入门即可。

producer.start

    /**
     * Start this producer instance.
     * 

* * * Much internal initializing procedures are carried out to make this instance prepared, thus, it's a must to invoke * this method before sending or querying messages. * *

* * @throws MQClientException if there is any unexpected error. */ @Override public void start() throws MQClientException { this.defaultMQProducerImpl.start(); } 复制代码

主要做了下列事情(核心事情):

  • 一些配置检查。
  • 构建与namesrv通信的netty客户端。
  • 默认每30s与namesrv交换获取broker相关信息。
  • 默认每30s去掉失效的broker信息以及发送心跳到所有broker上面。

构建Message对象

producer是以Message对象进行发送的,看看Message构造:

    public Message() {
    }

    public Message(String topic, byte[] body) {
        this(topic, "", "", 0, body, true);
    }

    public Message(String topic, String tags, String keys, int flag, byte[] body, boolean waitStoreMsgOK) {
        this.topic = topic;
        this.flag = flag;
        this.body = body;

        if (tags != null && tags.length() > 0)
            this.setTags(tags);

        if (keys != null && keys.length() > 0)
            this.setKeys(keys);

        this.setWaitStoreMsgOK(waitStoreMsgOK);
    }

    public Message(String topic, String tags, byte[] body) {
        this(topic, tags, "", 0, body, true);
    }

    public Message(String topic, String tags, String keys, byte[] body) {
        this(topic, tags, keys, 0, body, true);
    }
复制代码

备注: 主要就是topic、tags、以及body真实内容等。

send发送

SendResult sendResult = producer.send(msg);
复制代码

进行发送处理。下面我们重点看看send如何处理。

发送send核心分析

发送的几种方式:同步 异步 oneway(应该选择哪种,需要自己根据情况进行判断)

以同步发送为例子,默认超时时间为3s,

SendResult sendResult = producer.send(msg);
复制代码

这个就是发送的触发方法,我们一直跟进去就行了,**第一初步感受:**通过跟踪进去第一感觉就是涉及到了JUC相关使用,大量运用享元模式(本质一个map进行缓存)以及netty使用。

核心逻辑:

代码就不大量复制了,需要的github里面获取基于rocketmq4.1.0加详细中文代码注释 。欢迎大家 star、fork !

  • 判断服务是否可用? 不可用直接结束流程。

  • 消息的验证:

  • 获取topic路由信息

    缓存中有就获取,没有就namesrv交互一次(也可能2次)由于topic信息在broker服务端不一定存在,如果不存在就用默认的(TBW102)。

封装请求头信息:

// Namesrv 根据Topic获取Broker Name、队列数(包含读队列与写队列)
 public static final int GET_ROUTEINTO_BY_TOPIC = 105;
复制代码

namesrv服务端接受到这个请求的处理情况。

最后得到的路由信息类似下面的:

  • 发送模式是sync 会有3次其他1次

    //发送模式是sync 会有3次其他1次
    int timesTotal = communicationMode == CommunicationMode.SYNC ? 1 + this.defaultMQProducer.getRetryTimesWhenSendFailed() : 1;
    复制代码
  • 选择一个queue

    如何选择发送那个broker的那个queueid上面?(客户端自己负载),由于broker相关信息缓存在客户端里面,问题来了(由于30s会同步一次信息,那么在30s之内broker出现问题会怎么样呢? )rocketmq是这样处理的:sendLatencyFaultEnable开关是否打开

    1.打开--> 有多长时间内不可用情况

    2.不打开(默认)-->直接随机一个(如果带了lastBrokerName不为空 尽量换不是这个broker的,如果都没有又是随机一个)

  • 调用sendKernelImpl发送消息 发送消息核心

    根据broker的name获取到ip地址,如果通道没有建立并且保存。

    设置设置UNIQ_id,里面保护客户端ip地址信息。

    发送的时候 会有钩子函数提供执行(禁止消息钩子 ,发送消息钩子(executeSendMessageHookBefore、executeSendMessageHookAfter)。

    构建SendMessageRequestHeader,包括生成消息时间戳,所以各各机器时间最好一致,(这样后期也可以查下broker接受消息花了多少时间)。

  • 根据发送消息模式,选择发送方式

    下面这次主要看同步发送情况。

    如果1情况执行nettywriteAndFlush发送成功者跳出来,到达3情况进行等等最多等待3s。这里什么时候唤醒呢? 其实是在broker情况响应客户端的时候进行唤醒的:

    备注: 这里使用CountDownLatch异步转同步的。

    如果是2情况表示发送失败,直接唤醒3情况不进行阻塞了(最后抛异常表示发送失败)

  • 更新broker可用时间

  • retryAnotherBrokerWhenNotStoreOK情况判断

    如果设置为retryAnotherBrokerWhenNotStoreOK为true之后,在发送失败的时候,会选择换一个broker。

  • 如下异常continue,进行发送消息重试

客户端发送流程大概到这里就分析完成了。


如果读完觉得有收获的话,欢迎点赞、关注、加公众号【匠心零度】,查阅更多精彩历史!!!

加入知识星球,一起探讨!

你可能感兴趣的:(RocketMQ(八):消息发送)