纵有疾风起
人生不言弃

聊一聊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 的架构原理吗?

聊一聊RocketMQ的注册中心NameServer插图

文章转载于:https://www.cnblogs.com/lm970585581/p/13607403.html

原著是一个有趣的人,若有侵权,请通知删除

未经允许不得转载:起风网 » 聊一聊RocketMQ的注册中心NameServer
分享到: 生成海报

评论 抢沙发

评论前必须登录!

立即登录