RocketMQ源码分析之NameServer

1、RocketMQ组件概述

• NameServer
  NameServer相当于配置中心，维护Broker集群、Broker信息、Broker存活信息、主题与队列信息等。NameServer彼此之间不通信，每个Broker与集群内所有的Nameserver保持长连接。

2、源码分析NameServer

本文不对 NameServer 与 Broker、Producer 集群、Consumer 集群的网络通信做详细解读（该系列后续专门进行讲解）

本文重点关注 NameServer 作为 MQ 集群的配置中心存储什么信息。

2.1 源码分析NamesrvController

NameserController 是 NameServer 模块的核心控制类。

2.1.1 NamesrvConfig

NamesrvConfig,主要指定 nameserver 的相关配置属性：

• kvConfigPath(kvConfig.json)。
• mqhome/namesrv/namesrv.properties。
• orderMessageEnable，是否开启顺序消息功能，默认为false。

2.1.2 ScheduledExecutorService

private final ScheduledExecutorService scheduledExecutorService = Executors.

NameServer 定时任务执行线程池，默认定时执行两个任务：

• 任务1、每隔 10s 扫描 broker ,维护当前存活的Broker信息。
• 任务2、每隔 10s 打印KVConfig 信息。

2.1.3 KVConfigManager

读取或变更NameServer的配置属性，加载 NamesrvConfig 中配置的配置文件到内存，此类一个亮点就是使用轻量级的非线程安全容器，再结合读写锁对资源读写进行保护。尽最大程度提高线程的并发度。

2.1.4 RouteInfoManager

NameServer 数据的载体，记录 Broker、Topic 等信息。

    private final static long BROKER_CHANNEL_EXPIRED_TIME = 1000 * 60 * 2;                                         //@1
    private final ReadWriteLock lock = new ReentrantReadWriteLock();                                                      //@2
    private final HashMap<String/* topic */, List<QueueData>> topicQueueTable;                                   //@3
    private final HashMap<String/* brokerName */, BrokerData> brokerAddrTable;                                  //@4
    private final HashMap<String/* clusterName */, Set<String/* brokerName */>> clusterAddrTable;    //@5
    private final HashMap<String/* brokerAddr */, BrokerLiveInfo> brokerLiveTable;                                //@6

代码@1，NameServer 与 Broker 空闲时长，默认2分钟，在2分钟内 Nameserver 没有收到 Broker 的心跳包，则关闭该连接。

代码@2，读写锁，用来保护非线程安全容器 HashMap。

代码@3，topicQueueTable，主题与队列关系，记录一个主题的队列分布在哪些Broker上，每个Broker上存在该主题的队列个数。QueueData队列描述信息，对应如下属性：

private String brokerName;           // broker的名称

private int readQueueNums;           // 读队列个数

private int writeQueueNums;          // 写队列个数

private int perm;                    // 权限操作

代码@4，brokerAddrTable,所有 Broker 信息，使用 brokerName 当key, BrokerData 信息描述每一个 broker 信息。

// broker所属集群
private String cluster;                           

// broker name
private String brokerName;

 broker 对应的IP:Port,brokerId=0表示Master,大于0表示Slave。             

代码@5，clusterAddrTable，broker 集群信息，每个集群包含哪些 Broker。

代码@6，brokerLiveTable，当前存活的 Broker,该信息不是实时的，NameServer 每10S扫描一次所有的 broker,根据心跳包的时间得知 broker的状态，该机制也是导致当一个 Broker 进程假死后，消息生产者无法立即感知，可能继续向其发送消息，导致失败（非高可用），如何保证消息发送高可用，请关关注该系列后续文章。

2.1.5 BrokerHousekeepingService

BrokerHouseKeepingService 实现 ChannelEventListener接口，可以说是通道在发送异常时的回调方法（Nameserver与 Broker的连接通道在关闭、通道发送异常、通道空闲时），在上述数据结构中移除已宕机的 Broker。

public interface ChannelEventListener {
    void onChannelConnect(final String remoteAddr, final Channel channel);

    void onChannelClose(final String remoteAddr, final Channel channel);

    void onChannelException(final String remoteAddr, final Channel channel);

    void onChannelIdle(final String remoteAddr, final Channel channel);

2.1.6 NettyServerConfig、RemotingServer 、ExecutorService

这三个属性与网络通信有关，NameServer 与 Broker、Producer、Consume 之间的网络通信，基于 Netty实现。本文借这个机会再次探究 Netty 线程模型与 Netty实战技巧。

源码分析网络通讯之前，我们关注如下问题：

• NettyServerConfig 的配置含义
• Netty 线程模型中 EventLoopGroup、EventExecutorGroup 之间的区别与作用
• 在 Channel 的整个生命周期中，如何保证 Channel 的读写事件至始至终使用同一个线程处理

首先我们先过一下NettyServerConfig中的配置属性：

    private int listenPort = 8888;
    private int serverWorkerThreads = 8;
    private int serverCallbackExecutorThreads = 0;
    private int serverSelectorThreads = 3;
    private int serverOnewaySemaphoreValue = 256;
    private int serverAsyncSemaphoreValue = 64;
    private int serverChannelMaxIdleTimeSeconds = 120;

    private int serverSocketSndBufSize = NettySystemConfig.socketSndbufSize;
    private int serverSocketRcvBufSize = NettySystemConfig.socketRcvbufSize;

我们带着上面的疑问开始源码分析 org.apache.rocketmq.remoting.netty.NettyRemotingServer。