关于rocketmq:RocketMQ学习八NameServer分析

7次阅读

共计 2228 个字符，预计需要花费 6 分钟才能阅读完成。

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 集群信息不统一对音讯发送端与音讯生产端别离有什么影响。

对发送端的影响
假如有如下场景：

因为一些起因 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 集群路由信息不统一并不会导致音讯发送不可用。
对生产端的影响(待定，这一块须要看完 broker 与 consumer 之后再写，须要弄清楚反复生产)

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

正文完