《RockectMQ实战与原理解析》Chapter4-分布式消息队列的协调者

4.1 NameServer 的功能

        NameServer 是整个消息队列中的状态服务器，集群的各个组件通过它来了解全局的信息 。 同时，各个角色的机器都要定期向 NameServer 上报自己的状态，超时不上报的话， NameServer 会认为某个机器出故障不可用了，其他的组件会把这个机器从可用列表里移除。

        NamServer 可以部署多个，相互之间独立，其他角色同时向多个 NameServer机器上报状态信息，从而达到热备份的目的。 NameServer 本身是无状态的，也就是说 NameServer 中的 Broker 、 Topic 等状态信息不会持久存储，都是由各个角色定时上报并存储到内存中的（NameServer 支持配置参数的持久化， 一般用不到） 。

         4.1.1 集群状态的存储结构 

        org.apache.rocketmq.namesrv.routeinfo.RouteInfoManager有五个变量RouteInfoManager.javahttps://gitee.com/apache/rocketmq/blob/develop/namesrv/src/main/java/org/apache/rocketmq/namesrv/routeinfo/RouteInfoManager.java

    /**
     *      这个结构的 Key 是 Topic 的名称，它存储了所有 Topic的属性信息。
     *  Value 是个 QueueData 队列 ， 队里的长度等于这个 Topic数据存储的
     *  Master Broker 的个数， QueueData 里存储着 Broker 的名称、读写
     *  queue 的数量 、 同步标识等
     */
    private final Map<String/* topic */, Map<String, QueueData>> topicQueueTable;
    
    /**
     *      以 BrokerName 为索引 ，相同名称的 Broker 可能存在多台机器， 一个
     *   Master 和多个 Slave 。 这个结构存储着一个 BrokerName 对应的属性信
     *   息，包括所属的 Cluster 名称， 一个 Master Broker 和多个 Slave Broker 
     *   的地址信息 。
     */
    private final Map<String/* brokerName */, BrokerData> brokerAddrTable;
    
    /**
     *      存储的是集群中 Cluster 的信息，结果很简单，就是一个 Cluster 名称对
     *  应一个由 BrokerName 组成的集合。
     */
    private final Map<String/* clusterName */, Set<String/* brokerName */>> clusterAddrTable;

    /**
     *       这个结构和 BrokerAddrTable 有关系，但是内容完全不同，这个结构的
     *  Key 是 BrokerAddr ，也就是对应着一台机器， BrokerAddrTable 中的 Key
     *  是 BrokerName ， 多个机器的 BrokerName 可以相同 。 BrokerLiveTable
     *  存储的内容是这台 Broker 机器的实时状态，包括上次更新状态的时间戳， 
     *  NameServer 会定期检查这个时间戳 ，超时没有更新就认为这个 Broker 无效了，
     *  将其从 Broker 列表里清除。
     */
    private final Map<BrokerAddrInfo/* brokerAddr */, BrokerLiveInfo> brokerLiveTable;

    /**
     *      FilterServer 是过滤服务器，是 RocketMQ 的一种服务端过滤方式，一
     *  个 Broker 可以有 一个或多个 FilterServer 。 这个结构的 Key 是 Broker
     *  的地址， Value 是和这个 Broker 关联的多个 FilterServer 的地址。
     */
    private final Map<BrokerAddrInfo/* brokerAddr */, List<String>/* Filter Server */> filterServerTable;

        4.1.2 状态维护逻辑

        因为其他角色会主动向Name Server 上报状态，所以 NameServer 的主 要逻 辑在 DefaultRequest ­Processor 类中，根据上报消息里的请求码做相 应 的处理， 更新存储的对应信息 。 此外，连接断开的 事 件也 会 触发状态 更新，具体逻辑在org.apache.rocketmq.namesrv.routeinfo.BrokerHousekeepingService

        当 NameServer 和 Broker 的长连接断掉以后， onChannelDestroy 函数会被调用，把这个 Broker 的信息清理出去 。

        NameServer 还有定时检查时间戳的逻辑 ， Broker 向 NameServer 发送的心跳会更新时间戳， 当 NameServer 检查 到时间戳长时间没有更新后，便会触发清理逻辑 。

org.apache.rocketmq.namesrv.NamesrvController 每5s检查一次

 4.2 各个角色间的交互流程

        4.2.1 交互流程源码分析

        创建 Topic 的代码 是 在  org.apache.rocketmq.tools.command.topic 里的UpdateTopicSubCommand 类中，创建 Topic 的命令 是 updateTopic

UpdateTopicSubCommand.javahttps://gitee.com/apache/rocketmq/blob/develop/tools/src/main/java/org/apache/rocketmq/tools/command/topic/UpdateTopicSubCommand.java

         org.apache.rocketmq.tools.command.topic.UpdateTopicSubCommand#execute 调用org.apache.rocketmq.tools.admin.DefaultMQAdminExt#createAndUpdateTopicConfig

是向 NameServer 发 送注 册 信 息， NameServer 完 成创 建Topic 的逻辑后，其他客户端才能发现新增 的 Topic ，相关逻辑在org.apache.rocketmq.namesrv. routeinfo.RouteInfoManager#registerBroker，首先更新 Broker 信息，然后对每个 Master 角色的 Broker ，创建一个QueueData 对象。 如果是新建 Topic ，就是添加 QueueData 对象；如果是修改Topic ，就是把旧的 QueueData 删除 ， 加入新的 QueueData 。

        4.2.2 为何不用 ZooKeeper

        RocketMQ 的架构设计决定了它不需要进行 Master 选举，用不到这些复杂的功能，只需要一个轻量级的元数据服务器就足够了 。 5 张图告诉你 RocketMQ 为什么不使用 Zookeeper 做注册中心 - 腾讯云开发者社区-腾讯云 (tencent.com)https://cloud.tencent.com/developer/article/2118883

4.3 底层通信机制 

        4.3.1 Remoting 模块

        RocketMQ 的通信相关代码在 Remoting 模块里，先来看看主要类结构 

 

 NettyRemotingClient、NettyRemotingServer而 且 都继承了NettyRemoting-Abstract 类 。通过上面的封装 ， RocketMQ 各个模块间的通信， 可以通过发送统一格式的自定义消息 （ RemotingCommand ） 来完成， 各个模块间的通信实现简洁明了 。

        比如 NameServer 模 块中， NameServerController 有 一 个 remotingServer 变量 ， NameServer 在启动时初始化各个变量 ， 然后启 动 remotingServer 即可，剩下 NameServer 要 做的 是专心实现处理 RemotingCommand 的逻辑。 

org.apache.rocketmq.namesrv.processor.DefaultRequestProcessor#processRequest

 

        4.3.2 协议设计和编解码

        RocketMQ 自己定义了一个通信协议，使得模块间传输的二进制消息和有意义 的内 容之间互相转换。  

         1 ）第一部分是大端 4 个字节整数，值等于第二、三、 四部分长度的总和；

        2 ）第二部分是大端 4 个字节整数，值等于第三部分的长度；

        3 ）第三部分是通过 Json 序列化的数据；

        4 ）第四部分是通过应用自定义二进制序列化的数据。

        消息的解码过程在 RemotingCommand 的 decode 函数里org.apache.rocketmq.remoting.protocol.RemotingCommand#decode(io.netty.buffer.ByteBuf)

org.apache.rocketmq.remoting.protocol.RemotingCommand#encode

        4.3.3 Netty 库 

        RocketMQ 是基于 Netty 库来完成 RemotingServer 和 RemotingClient 具体的通信实现的， Netty 是个事件驱动的网络编程框架，它屏蔽了 Java Socket 、 NIO等复杂细节，用户只需用好 Netty ，就可以实现一个“ 网络编程专家＋并发编程专家”水平的 Server 、 Client 网络程序 。 应用 Netty 有一定的门槛，需要了解它的 EventLoopGroup 、 Channel 、 Handler 模型以及各种具体的配置。 RocketMQ利用 Netty 实现的通信类是 NettyRemotingServer 和 NettyRemotingClient ，用户也可以参考这两个类的实现来学习使用 Netty 。