关于rocketmq:RocketMQ学习八NameServer分析

NameServer作为RocketMQ的注册核心，次要存储了哪些信息，如何存储，信息有变更时如何告诉进来的？上面咱们带着这几个问题一起剖析下NameServer

一，NameServer记录的信息
NameServer作为RocketMQ的注册核心，次要存储着队列与Topic关系列表，broker列表，集群与broker关系列表，以后存活的broker列表

public class RouteInfoManager {
    
    //Broker向NameServer上报心跳的最大工夫
    private final static long BROKER_CHANNEL_EXPIRED_TIME = 1000 * 60 * 2;
    private final ReadWriteLock lock = new ReentrantReadWriteLock();
    //主题与队列的关系列表，其中队列里有读队列与写队列
    private final HashMap<String/* topic */, List<QueueData>> topicQueueTable;
    private final HashMap<String/* brokerName */, BrokerData> brokerAddrTable;//所有broker信息
    private final HashMap<String/* clusterName */, Set<String/* brokerName */>> clusterAddrTable;//每个集群包含哪些broker
    //以后存活broker，因为nameserver 10S扫描一次所以会有提早
    private final HashMap<String/* brokerAddr */, BrokerLiveInfo> brokerLiveTable;
    //记录每个Broker别离应用了哪些音讯过滤服务器
    private final HashMap<String/* brokerAddr */, List<String>/* Filter Server */> filterServerTable;

}

• topicQueueTable：各topic属于那个broker上；每个topic下有多少队列；各队列的读写数量及权限
• brokerAddrTable：各broker id与address关系，会辨别broker的master与slave
• clusterAddrTable:各cluster蕴含的broker
• brokerLiveTable:以后存活的broker，会有肯定的提早
• filterServerTable：每个Broker别离应用了哪些音讯过滤服务器

如果下面的数据产生了变动NameServer如何解决呢？答案是通过BrokerHousekeepingService进行监听，它实现了ChannelEventListener接口，如果通道产生了变动，比方Nameserver与 Broker的连贯通道在敞开、通道发送异样、通道闲暇时，会触发BrokerHousekeepingService的回调，而后移除相应的Broker。

二，NameServer的工作机制

RocketMQ的路由信息次要是指Topic的队列信息，也就是队列散布在哪个Broker里。

• NameServer 命名服务，集群部署，各节点间不通信
• Broker 音讯服务器，每隔30S向NameServer发送心跳信息
• Producer,Consumer 音讯客户端，同一时间内只会连一个NameServer服务器，每隔30S更新一次Topic信息

NameServer启动后会每隔10S扫描Broker集群，如果肯定工夫内(120S)内未收到Broker心跳信息，NameServer会将此Broker移除，以进步音讯发送高可用。这就是典型的PULL模式，而ZK则是一种PUSH的模式，ZK是通过事件机制来实现的PUSH模式，这种模式一个长处就是具备实时性，一旦服务端有变动，客户端能够马上贴到ZK的告诉，但这种强一制性是就义了可用性的，这会导致服务在肯定工夫内不可用。

但PULL模式也有它的问题，NameServer存储的路由信息如果产生了变动它不会被动告诉客户端，面是须要客户端被动去拉取最新的路由信息(肯定频率的定时工作拉取)，这样显然是不及时的。RocketMQ是如何应答的呢？答案是通过客户端的重试与Broker的躲避策略(能够参考后面写的RocketMQ学习四-音讯发送高可用设计)。
咱们能够剖析下，如果NameServer集群信息不统一对音讯发送端与音讯生产端别离有什么影响。

1. 对发送端的影响
   假如有如下场景：
   
   因为一些起因Namerserver-2里的broker信息只有broker-a能够应用，对于音讯发送端的Producer-1能够将音讯发送到broker-a与broker-b两个broker上且Consumer-2能够失常生产，而Producer-2则只能将音讯发送到broker-a上且Consumer-1只能生产到broker-a上的音讯，这样结果是压力全在broker-a上，但服务还是可用的，通过人工干预后问题能够解决。所以NameServer集群路由信息不统一并不会导致音讯发送不可用。
2. 对生产端的影响(待定，这一块须要看完broker与consumer之后再写，须要弄清楚反复生产)

参考的文章：
RocketMQ4.0源码剖析之-路由治理
Nameserver 背地的设计理念