NameServer、Zookeeper,傻傻分不清楚

消息队列RocketMQ版是阿里云基于Apache RocketMQ构建的低延迟、高并发、高可用、高可靠的分布式消息中间件。

我们知道RocketMQ是个消息队列,这个消息队列是分为多个组件的,其中包括broker、producer、consumer等,那么这些个组件之间如何交互呢?或者说它们如何获得对方的状态呢

大鱼相信聪明的你应该已经猜到了,就是通过一个注册中心来控制,其实大鱼本人我在写这篇文章之前一直在纠结到底如何称呼NameServer在RocketMQ中的地位呢?

说是大脑吧,但是它又不完全算是指挥中心,也没有存储消息(消息存储在broker中),大脑中应该是存储这这些才有资格叫做大脑吧;要说不是大脑吧,它又存在一部分的指挥作用,producer发送消息,需要先通过NameServer获取到broker和Topic的对应关系,获取到broker的地址信息,再去长连接broker来发送消息,而且还和broker之间有着心跳机制来维持broker的存活状态,维持整个集群的稳定性和可用性

所以,大鱼我给NameServer起名叫做 伪大脑 ;

啥玩意?伪大脑,那是不是还有真大脑呢?真大脑是什么?

我真是太喜欢好奇的你了,一猜你就是风华正茂,爱好学习的中华好儿女,没错,我卖关子其实就是下一篇咱们要一起学习的broker,这是RocketMQ中最核心的了,因为很多逻辑控制都是在这里边完成(定时延时、半消息),还有存储消息的文件、存储消费offset的文件等等

NameServer

NameServer是什么

知其然,再知其所以然,那到底NameServer是个什么东西呢?

NameServer是一个非常简单的Topic路由注册中心,其角色类似Dubbo中的zookeeper,支持Broker的动态注册与发现。NameServer是一个几乎无状态节点,可集群部署,节点之间无任何信息同步。

NameServer存储Topic和Broker的信息,Broker启动的时候会向所有的NameServer注册。Producer在发送消息之前会先从NameServer获取Broker地址列表,按照负载均衡算法从列表中选择一台Broker服务器发送消息

NameServer和Broker保持长连接,每隔30s检测Broker是否存活,如果Broker宕机,从路由注册表中删除。路由变化不会马上通知Producer,这样实现降低了NameServer实现复杂度,Producer会通过容错机制来保证消息发送高可用。

Producer与Name Server集群中的其中一个节点(随机选择)建立长连接,定期从Name Server取Topic路由信息,并向提供Topic服务的Master建立长连接,且定时向Master发送心跳。Producer完全无状态,可集群部署。

Consumer与Name Server集群中的其中一个节点(随机选择)建立长连接,定期从Name Server取Topic路由信息,并向提供Topic服务的Master、Slave建立长连接,且定时向Master、Slave发送心跳。Consumer既可以从Master订阅消息,也可以从Slave订阅消息,订阅规则由Broker配置决定。

NameServer集群

RocketMQ集群,应该是线上采用的相当多的一种架构了,分为四个主要组成部分:生产者集群、消费者集群、NameServer集群和Broker集群,其中的NameServer集群是什么样子的呢?这个还挺有意思的,和别的集群不太一样,一起来看看为啥

我们了解的集群,一般都是互帮互助,起到一个高可用的作用;绝大多数集群应该都是这个样子的,而NameServer集群却不是这个样子的,NameServer集群说白了其实属于一个伪集群,为什么这么说呢?

因为NameServer集群中的多个节点是互不交互的,就是等同于多个独立的NameServer机器部署在NameServer集群中,每个机器都可以单独支持这个集群的运转,多个机器的作用其实就是备份的作用

NameServer集群如何部署

NameServer 是整个集群的路由中心,如果没有了它,生产者往哪个 Broker 投递消息都不知道,没有了它,会很麻烦!

为了保证高可用性,NameServer 必然是需要支持多台部署的。如果 NameServer 就部署一台机器的话,一旦它宕机了会导致 RocketMQ 集体出现故障。

所以多机器部署保证了任何一台 NameServer 宕机,其他机器上的 NameServer 可以继续对外提供服务。

如果NameServer集群中的一个机器挂掉了怎么办,对集群有什么影响

对于整个RocketMQ集群来说问题不大,因为设计优秀的RocketMQ集群不会因为一台NameServer机器挂掉而导致整个集群受影响甚至不可用。一般我们会有报警系统来报警关于NameServer机器挂掉的信息,有相应的运维人员再去处理

NameServer作用

NameServer是一个非常简单的Topic路由注册中心,其角色类似Dubbo中的zookeeper,支持Broker的动态注册与发现。NameServer是一个几乎无状态节点,可集群部署,节点之间无任何信息同步。

NameServer在RocketMQ集群中起到了类似于注册中心的作用,我们先来看下NameServer的源码架构

其实结构也很简单,不算复杂,大家如果有兴趣研究,可以花点时间去研究,源码地址:

https://github.com/rocketmq

NameServer在RocketMQ中的作用大概大鱼同学给分了三类,叫做路由管理、路由发现和路由删除,也很好理解,来,我给大家简单解释下

  • 路由管理就是保存着broker的活跃列表和Topic对应的关系
  • 路由注册和发现就是Topic对应的broker信息发生变化时的更新(非实时性)
  • 路由删除就是对于broker机器宕机或者关闭时自动删除相应路由

我们知道broker和NameServer的关系是很紧密的,单个broker会和所有的NameServer保持长连接,broker启动时会轮询所有的NameServer并进行注册

broker每隔30秒(此时间没有办法更改的哦,切记哦)会向所以的NameServer发送心跳,心跳包含了所有的Topic信息

由此可以看出:如果broker中包含太多Topic,心跳信息过大的话可能会造成网络传输较慢

NameServer每隔10秒也会扫描所有存活着的broker的,这个时间也是无法更改的,若某个连接2分钟内(当前时间与最后更新时间差值超过2分钟,此时间无法更改)没有发送心跳数据,则断开连接,一旦连接断开,nameserver会感知,感知会有稍稍的延迟,为啥延迟我应该不用说了吧?

接着就是更新topc与队列的对应关系,但不会通知生产者和消费者

路由管理:保存着broker的活跃列表和Topic对应的队列列表

NameServer保存着活跃的broker列表,包括master和slave;NameServer用来保存所有的Topic和Topic对应的所有队列的列表;NameServer用来保存所有的broker的filter列表

这些在RouteInfoManager这个类中都有

每个属性通过名字就能清楚的知道是什么意思,之所以能用非线程安全的HashMap,是因为有读写锁lock来对HashMap的修改做保护。

我们注意到保存broker的Map有两个,即brokerAddrTable用来保存所有的broker列表和brokerLiveTable用来保存当前活跃的broker列表,而BrokerData用来保存broker的主要新增,而BrokerLiveInfo只用来保存上次更新(心跳)时间

你几乎可以在NameServer这里知道topic相关的所有信息,包括topic有哪些队列,这些队列在那些broker上等。

DefaultRequestProcessor是NameServer的默认请求处理器,他处理了定义在rocketmq-common模块中RequestCode定义的部分请求,比如注册broker、注销broker、获取topic路由、删除topic、获取broker的topic权限、获取NameServer的所有topic等

路由注册和发现:Broker的启动注册和Topic的关系变动

Broker在启动时向所有的NameServer心跳语句,每隔30S向所有NameServer发起心跳包。NameServer收到心跳包后更新缓存。NameServer每隔10S扫描brokerLiveTable,如果连续120S没有收到心跳包,则NameServer移除Broker的路由信息同时关闭Socket连接。

路由注册在broker启动时触发,broker启动时会和所有NameServer创建心跳连接,向NameServer发送Broker的相关信息。NameServer在RouteInfoManager类中维护了Broker相关信息的缓存,进行更新动作。更新时用了读写锁,既保证了极高并发场景下的读效率,又避免了并发修改缓存。

路由发现:RocketMQ的路由发现是非实时的。当topic对应的路由信息发生变化,NameServer并不会通知给客户端。而是由客户端定时拉取Topic对应的最新路由。不实时的路由发现引起的问题由客户端进行解决,保证了NameServer逻辑的简洁。客户端定时向NameServer发起请求GET_ROUTEINFO_BY_TOPIC,获取对应的信息

路由删除:对于宕机或者关闭的broker,自动删除相应的路由信息

路由删除的触发点有两个:

  • NameServer启动时开启的定时任务,每隔10s扫描一次brokerLiveTable,检测上次心跳包与当前系统时间差,如果时间差大于120s,则移除Broker的相关信息。
  • Broker正常关闭,会向NameServer发送UNREGISTER_BROKER消息。

其实初期RocketMQ采用的是zookeeper作为注册中心的,后来为什么改成自研的NameServer了?

这个问题其实我也不想太多的多说,这个可能需要了解zookeeper,如果不了解这个东西的话,其实我说了也是没啥大用的

首先,zookeeper中最主要的功能就是master的选举,但是呢?对于RocketMQ不太合适,你想啊,RocketMQ中的master并不会存在全部的Topic信息,所以选择master没什么意义

其次,对于RocketMQ来说,这个注册中心的作用不仅要保存相关的信息(broker活跃列表、Topic对应信息等),还有就是需要一些逻辑来处理相应的数据,比如每隔10秒检测一次活跃的broker来更新列表,这些逻辑如果换做是zookeeper的客户端来处理的话,算是比较麻烦的

因此,既然zookeeper对于RocketMQ来说是属于一个重量级的注册中心,所以不如自己写一个简易的注册中心来实现,像上面说的集群,NameServer集群是属于伪集群,节点之间不存在相应的交互,只是起到一个备份的作用,这样使得RocketMQ集群变得更加灵活。

原文地址:https://mp.weixin.qq.com/s/nDBbOyfo9I1o3LHgYg2XgQ

本文链接:https://my.lmcjl.com/post/8824.html

展开阅读全文

4 评论

留下您的评论.