【RocketMQ】NameServer总结

rocketmq,nameserver,总结 · 浏览次数 : 221

小编点评

**NameServer的作用:** - 注册中心,提供服务注册和服务发现的功能。 - 集群部署中,每个NameServer节点都是对等的,所以需要向每一个节点进行注册,这样每个节点都会有一份Broker的注册信息。 - 由于NameSever每个节点都是对等的,所以生产者和消费者需要感知所有的NameServer(RocketMQ有对应的配置项可以配置NameServer服务列表)。 **使用zookeeper的缺点:** - Zookeeper的实现复杂,引入zookeeper会增加系统的复杂度,并且zookeeper在CAP中选择了CP,也就是一致性和分区容错性,从而牺牲了可用性,为了保持数据的一致性会在一段时间内会不可用。 - zookeeper不可用的时候,如果有消费者或生产者刚好需要从NameServer拉取信息,由于服务不可用,导致生产者和消费者无法进行消息的生产和发送,在高并发或者数据量比较大的情况下,大量的消息无法发送/无法消费影响是极大的,而如果选择CP的ZooKeeper,在不可用的情况下,消费者和生产者无法进行消息的生产和发送。 **RocketMQ的注册中心设计:** - 为了提升性能以及应对高并发的情况,一般都会使用多个Broker进行集群部署。 - RocketMQ设计者选择自己实现注册中心,简单并且轻量,并且有一定的方案来保证数据的最终一致性以及消息发送的可靠性。

正文

NameServer是一个注册中心,提供服务注册和服务发现的功能。NameServer可以集群部署,集群中每个节点都是对等的关系(没有像ZooKeeper那样在集群中选举出一个Master节点),节点之间互不通信。
服务注册
Broker启动的时候会向所有的NameServer节点进行注册,注意这里是向集群中所有的NameServer节点注册,而不是只向其中的某些节点注册,因为NameServer每个节点都是对等的,所以Broker需要向每一个节点进行注册,这样每一个节点都会有一份Broker的注册信息。

服务发现
Broker向NameServer注册以后,生产者Producer和消费者Consumer就可以从NameServer中获取所有注册的Broker信息,不过由于NameSever每个节点是对等的,所以生产者和消费者需要感知所有的NameServer(RocketMQ有对应的配置项可以配置NameServer服务列表),之后选取一个NameServer从中获取Topic的路由信息,再向对应的Broker进行消息的发送和消费。

以生产者为例,在NameServer集群部署模式下,生产者会从多个NameServer中随机选取一个进行通信,从中拉取所有Broker的注册信息,并将拉取到的信息进行缓存,生产者知道了Broker的信息后,就可以得知Topic的分布情况,然后选取一个消息队列,与其所在的Broker通信进行消息的发送。如果通信的Nameservre宕机,消费者会轮询选择下一个NameServer。

为什么需要NameServer?

在使用RocketMQ的时候,为了提升性能以及应对高并发的情况,一般都会使用多个Broker进行集群部署,假设没有注册中心,对于Broker来说,如果想获取到集群中所有的Broker信息(生产者和消费者需要通过某个Broker获取整个集群的信息,从而得到Topic的分布情况),每个Broker都需要与其他Broker通信来交换信息,以此来得到集群内所有Broker的信息,在Broker数量比较大的情况下,会造成非常大的通信压力。

为什么不使用zookeeper这样的分布式协调组件?
首先zookeeper的实现复杂,引入zookeeper会增加系统的复杂度,并且zookeeper在CAP中选择了CP,也就是一致性和分区容错性,从而牺牲了可用性,为了保持数据的一致性会在一段时间内会不可用。

而NameServer在实现上简单,RocketMQ的设计者也许认为对于一个消息队列的注册中心来说,一致性与可用性相比,可用性更重要一些,至于一致性可以通过其他方式来解决。

假如选择了CP的ZooKeeper,先不考虑其他原因,在ZooKeeper不可用的时候,如果有消费者或生产者刚好需要从NameServer拉取信息,由于服务不可用,导致生产者和消费者无法进行消息的生产和发送,在高并发或者数据量比较大的情况下,大量的消息无法发送/无法消费影响是极大的,而如果选择AP,即便数据暂时处于不一致的状态,在心跳机制的作用下也可以保证数据的最终一致性,,所以RocketMQ选择了自己实现注册中心,简单并且轻量,并且有一定的方案来保证数据的最终一致性以及消息发送的可靠性。

举个例子,假如集群中有三个Broker(分别为 A、B、C),向三台NameServer进行了注册(也分别为A、B、C),生产者从NameServer中获取到了三个Broker的信息,如果此时BrokerA需要停止服务,分别通知三台NameServer需要下线,从NameServer中剔除该Broker的信息,由于网络或者其他原因,NameServer A和B收到了下线的请求,NameServer C并未收到,此时就处于数据不一致的状态,如果某个生产者与NameServer C进行通信,会认为Broker还处于可用的状态:

对于这种情况,首先NameServer与Broker之间会有一个心跳机制,NameServer定时检测在某个时间范围内是否收到了Broker发送的心跳请求,如果未收到,会认为该Broker不可用,将其剔除(在下面会讲到),所以对于NameServer来说,尽管数据会暂时处于不一致的状态,但是可以保证过一段时间之后恢复数据的一致性,也就是最终一致性。

对于生产者来说,既然可以从NameServer C中获取到Broker A的信息,那么生产者就认为Broker A可用,如果发送的消息所在的消息队列在Broker A中,就会与Broker A通信进行发送,但实际上Broker A实际上是不可用的,消息会发送失败,所以RocketMQ设计了消息重试机制(消息发送失败时重试)以及故障延迟机制(开启时,如果某个Broker不可用,会在一定时间内规避这个Broker)。

Broker注册

Broker启动后会开启定时向NameServer进行注册(发送心跳包)的任务,发送心跳包的时间间隔可以在配置文件中进行设置,但是最长不能超过10s,也就是说Broker最长10秒钟会向Nameserver发送一次心跳包。

NameServer收到Broker的注册请求(心跳包)后,会判断Broker之前是否已经注册过,如果未注册过将其加入到注册的Broker集合brokerAddrTable中,同时也会记录收到注册请求的时间,将其加入到brokerLiveTable中,里面记录了NameServer收到每个Broker发送心跳包的时间,在进行心跳检测的时候根据这个时间戳来判断是否在规定时间内未收到该Broker发送的心跳包。

读写锁
由于NameServer可能同时收到多个Broker的注册以及生产者或者消费者的拉取请求,为了保证数据的一致性(因为有读写请求同时发生或者写与写请求同时发生),在处理相关请求的时候需要加锁,为了提高性能,使用了ReadWriteLock读写锁,处理注册请求时会先添加写锁,处理拉取请求时添加读锁,这样如果某一时刻都是读的请求可以同时进行,互不影响,如果有写请求,其他请求就需要等锁释放才可以进行往下进行。如果不使用读写锁,直接对所有的请求加锁,会影响性能,实际上读与读之间并不需要加锁。

心跳检测

Nameserver在启动的时候会开启一个用于心跳检测的定时任务(每10s执行一次),定时扫描处于不活跃状态的Broker,如果在规定时间内未收到某个Broker的心跳包,会认为此Broker不可用,需要将其进行剔除。

上面说到brokerLiveTable保存了当前NameServer收到的心跳数据,里面记录了每一个Broker最近进行注册/发送心跳的时间戳,所以只需遍历brokerLiveTable,获取每一个Broker最近一次发送心跳的时间进行判断,如果上一次发送心跳的时间 + 过期时间(120s) 小于 当前时间,也就是超过120s没有收到某个Broker的心跳包,则认为此Broker已下线,将Broker移除

Broker下线

正常下线
当Broker下线的时候会向NameServer发起取消注册的请求,NameServer收到请求后会将Broker剔除。

异常下线

如果Broker异常宕机,或者发送给NameServer的取消注册请求由于某些原因并未发送成功,NameServer可能并未感知到Broker的下线,由于心跳机制定时检测的功能,会在一段时间后发现未收到Broker的心跳请求,主动将Broker剔除。

生产者和消费者

生产者和消费者都会定时从NameServer中更新Broker的注册信息,默认是30s进行一次更新:

public class MQClientInstance {
    private void startScheduledTask() {
         this.scheduledExecutorService.scheduleAtFixedRate(new Runnable() {

            @Override
            public void run() {
                try {
                   // 更新路由信息 
                   MQClientInstance.this.updateTopicRouteInfoFromNameServer();
                } catch (Exception e) {
                    log.error("ScheduledTask updateTopicRouteInfoFromNameServer exception", e);
                }
            }
        }, 10, this.clientConfig.getPollNameServerInterval(), TimeUnit.MILLISECONDS);
    }
}

对应的相关源码可参考:

【RocketMQ】【源码】NameServer的启动
【RocketMQ】【源码】Broker服务注册

与【RocketMQ】NameServer总结相似的内容:

【RocketMQ】NameServer总结

NameServer是一个注册中心,提供服务注册和服务发现的功能。NameServer可以集群部署,集群中每个节点都是对等的关系(没有像ZooKeeper那样在集群中选举出一个Master节点),节点之间互不通信。 **服务注册** Broker启动的时候会向所有的NameServer节点进行注册,

MQ系列7:消息通信,追求极致性能

MQ系列1:消息中间件执行原理 MQ系列2:消息中间件的技术选型 MQ系列3:RocketMQ 架构分析 MQ系列4:NameServer 原理解析 MQ系列5:RocketMQ消息的发送模式 MQ系列6:消息的消费 1 介绍 前面的章节我学习了 NameServer的原理,消息的生产发送,以及消息

MQ系列8:数据存储,消息队列的高可用保障

MQ系列1:消息中间件执行原理 MQ系列2:消息中间件的技术选型 MQ系列3:RocketMQ 架构分析 MQ系列4:NameServer 原理解析 MQ系列5:RocketMQ消息的发送模式 MQ系列6:消息的消费 MQ系列7:消息通信,追求极致性能 1 介绍 在之前的章节中,我们介绍了消息的发送

MQ系列9:高可用架构分析

MQ系列1:消息中间件执行原理 MQ系列2:消息中间件的技术选型 MQ系列3:RocketMQ 架构分析 MQ系列4:NameServer 原理解析 MQ系列5:RocketMQ消息的发送模式 MQ系列6:消息的消费 MQ系列7:消息通信,追求极致性能 MQ系列8:数据存储,消息队列的高可用保障 1

MQ系列10:如何保证消息幂等性消费

MQ系列1:消息中间件执行原理 MQ系列2:消息中间件的技术选型 MQ系列3:RocketMQ 架构分析 MQ系列4:NameServer 原理解析 MQ系列5:RocketMQ消息的发送模式 MQ系列6:消息的消费 MQ系列7:消息通信,追求极致性能 MQ系列8:数据存储,消息队列的高可用保障 M

MQ系列11:如何保证消息可靠性传输(除夕奉上)

MQ系列1:消息中间件执行原理 MQ系列2:消息中间件的技术选型 MQ系列3:RocketMQ 架构分析 MQ系列4:NameServer 原理解析 MQ系列5:RocketMQ消息的发送模式 MQ系列6:消息的消费 MQ系列7:消息通信,追求极致性能 MQ系列8:数据存储,消息队列的高可用保障 M

[转帖]RocketMQ - nameSrv和Broker

RocketMQ RocketMQ是一个统一的消息传递引擎,轻量级的数据处理平台。 Name Server Name Server充当路由消息的提供者,生产者(Producer)或消费者(Customer)可以通过Name Server查找各主题对应的Broker IP列表,多个Name Serve

记一次RocketMQ消费非顺序消息引起的线上事故

应用场景 C端用户提交工单、工单创建完成之后、会发布一条工单创建完成的消息事件(异步消息)、MQ消费者收到消息之后、会通知各处理器处理该消息、各处理器处理完后都会发布一条将该工单写入搜索引擎的消息、最终该工单出现在搜索引擎、被工单处理人检索和处理。 事故异常体现 1、异常体现 从工单的流转记录发现、

【主流技术】聊一聊消息队列 RocketMQ 的基本结构与概念

RocketMQ 是阿里巴巴在 2012 年开源的分布式消息中间件,目前已经捐赠给 Apache 软件基金会,并于 2017 年 9 月 25 日成为 Apache 的顶级项目。 作为经历过多次阿里巴巴双十一这种“超级工程”的洗礼并有稳定出色表现的国产中间件,以其高性能、低延时和高可靠等特性近年来...

RocketMQ 事件驱动:云时代的事件驱动有啥不同?

本文深入探讨了云时代 EDA 的新内涵及它在云时代再次流行的主要驱动力,包括技术驱动力和商业驱动力,随后重点介绍了 RocketMQ 5.0 推出的子产品 EventBridge,并通过几个云时代事件驱动的典型案例,进一步叙述了云时代事件驱动的常见场景和最佳实践。