聊一聊RocketMQ的注册中心NameServer

前言

上次我们一起了解了RocketMQ的基本架构原理，那简单的回顾一下RocketMQ的架构组成。

RocketMQ其实包含了四个核心部分，NameServer、Broker、Producer、Consumer。

具体什么含义请参考上一篇文章内容，这里就不再重复介绍了。

NameServer作为RocketMQ的注册中心，它关联着生产者和消费者之间的数据通信，同时又存储着Broker集群的各种部署信息，它十分的重要。

今天我们就从NameServer这个核心部分入手，开始更深入的理解一下RocketMQ的内部原理。

NameServer的部署

要搭建一个RocketMQ技术栈，必然要部署NameServer，那么NameServer是如何部署的呢？

其实上篇文章我们就提到过，NameServer是支持集群化部署的，可以保证高可用性。

我们都知道NameServer作为一个十分重要的核心组成部分，它一旦宕机，整个MQ就无法正常运转了。

所以NameServer是一定要部署多台机器，保证任何时候都能对外提供服务的。

Broker是如何向NameServer注册信息的

下一个问题，Broker是如何向NameServer注册信息的呢？

是不是有人会这么认为？比如我们有10台Broker机器，2个NameServer机器，其中5台互注册到一个NameServer上，另外5台会注册到另外的一个NameServer上，这样一来NameServer中的数据也就实现了分布式存储，有很高的可扩展性。那真实情况是这样吗？

答案是否定的，虽然我们经常接触分布式的理论，MQ也是解决分布式系统中各种问题的关键技术，但不代表所有的情况都适用于分布式存储。

试想一下，如果NameServer分布式存储Broker注册的信息，那生产者从NameServer获取信息时不是又面临着和Broker相同的问题了吗，不知道应该访问哪个NameServer，所以这样的方式是错误的。

RocketMQ的实际方案是，每个Broker都会向每个NameServer进行服务注册。

这样从NameServer获取数据时无论从哪台机器上都能获取到所有的数据，而且就算其中一个NameServer宕机了，其他NameServer也能继续提供服务。

系统是如何从NameServer获取信息的

了解了向NameServer注册信息的方式，那么系统是如何从NameServer中获取信息的呢？

首先我们要知道，系统想要从NameServer里获取到什么信息？

其实主要就获取到两个信息，一是整套的Broker集群列表，二是通过一定的算法选择要访问的Broker机器，可以称其为路由信息。

生产者和消费者自己每隔一段时间，主动去NameServer中拉取这些信息，其实RocketMQ的内部就是这么实现的。

Broker宕机了，NameServer是如何感知到的

在Broker向NameServer注册了自己的信息后，如果这个时候由于各种原因，Broker宕机了，此时如果不去告知NameServer，那么NameServer中的信息就是错误的，当系统获取信息时可能会出现将消息发送到宕机的Broker的情况，导致系统出错，所以NameServer中信息的准确性是很重要的，那么当Broker宕机时，NameServer是真么感知到的呢？

这就要讲到心跳检测了。

就和我们一样，如果心跳停止了，就意味着系统出现了问题，需要治疗了。

Broker会每隔30s向每一个NameServer发送心跳请求，证明自己还活着。而NameServer再接收到心跳请求后，就会记录下这台Broker发送心跳请求的时间。

然后，NameServer自己每10s会扫描一次所有Broker留下的心跳请求时间，如果发现哪台Broker留下来的心跳请求时间距离当前时间超过120s了，那么就会断定这台Broker已经挂掉了，就会更新自己的Broker列表信息。

系统是如果感知到Broker宕机的

刚才我们知道了Broker宕机后，NameServer是可以感知到的，但生产者和消费者系统如果不能感知到宕机的信息，问题还是不能解决的，那么系统是如何感知到Broker宕机的呢？难道只要有Broker宕机了，NameServer就要主动发送消息给各个系统吗？

这是不靠谱的，就算是NameServer主动发送消息给所有系统，也无法解决问题。

我们想一下，如果这时候Broker宕机了，但是同时生产者已经把消息发出来给这台宕机的Broker了，而这个时候NameServer经过心跳检测刚刚感知到这个情况，再去主动发送给这个生产者，这样当然不能解决问题，报错已经发生了。

再想一下，NameServer就算是不主动发送消息给生产者，上边我们已经了解每个系统间隔一段时间就会主动向NameServer拉取信息了，所以NameServer主动发送消息既不能保证实时性，又是一个多此一举的过程。

那么实际解决方案是什么呢？

针对这个问题，以后我们会在专门研究生产者的时候做更详细的讲解，欢迎小伙伴们持续关注H.U.C-王子的文章，带你更深入的走进消息中间件。

往期文章推荐：

什么是消息中间件？主要作用是什么？

常见的消息中间件有哪些？你们是怎么进行技术选型的？

你懂RocketMQ 的架构原理吗？