RocketMQ 之 NameServer

前言NameServer 引入

正如我们所知道在RocketMQ 中NameServer 其主要的作用是负责管理Broker节点信息。那我们为什么需要NameServer呢？在实际的生产过程中对于Broker节点来说我们肯定是以集群的方式进行部署的。那对于Producer 来说他们怎么知道要把消息发送到那个Broker 节点上面去呢？当新增一个Broker 节点的时候 Producer 它又是怎么感知的呢？这就引入了NameServer。

1、NameServer 如何感知Broker节点？

Broker 节点在启动的时候会把自己的路由信息注册到NameServer 上面去（如果Brooker 节点搭建的主备模式其从节点的路由信息也会被注册），那NameServer 有如何感知Broker 节点是否存活？其实在NameServer 和 Broker节点之间是存在心跳检测机制的。Broker每隔30秒会给所以的NameServer 发送心跳包，告诉每个NameServer自己还存活。当NameServer接收到Broker的心跳包时会更新Broker最近一次心跳检测时间。然后NameServer每隔10秒回去允许一个任务，去检测Broker的最近一次心跳时间，如果一个Broker超过120秒没有发送心跳那么则会认为这个Broker节点已经挂掉了，从而剔除Broker节点的路由信息。

2、生产者或消费者又如何或如Broker路由信息？

其实这种实现方式有两种：第一种方式是NameServer 主动向生产者或消费者推送消息告诉他Broker节点信息有那些。但这明显不靠谱。因为NameServer 不知道他要推送Broker信息给那些节点。第二种 方式是生产者或消费者每隔一段时间向NameServer 发送请求获取Broker节点信息，将Broker信息存储在本地。

3、生产者或消费者如何感知Broker节点信息是否存活？

这其实靠生产者或消费者定时从NameServer 中拉去最新的Broker信息。如果此时Broker节点已经挂了，系统还未拉去最新的Broker信息的话这时请求可能会失败，这时只能靠把消息转发到另一个Broker节点上了。

NameServer 高可用

NameServer 他负责去管理集群中Broker的信息，让MQ系统知道有那些Broker节点，所以NameServer 高可用是必须要保证的。如果我们通过集群的方式搭建NameServer 集群，这时Broker的信息是分布存储在每个NameServer上还是，每个NameServer上都有完整的Broker信息呢？答案肯定是第二种。因为如果我们把Broker信息分布存储在NameServer上，当某个NameServer 宕机的时候这会导致部分Broker的节点信息丢失。