一张图进阶 RocketMQ – NameServer
- 2022 年 6 月 17 日
- 笔记
- mq, nameserver, RocketMQ, RocketMQ 架构, 消息中间件, 消息队列
前言
「三此君看了好几本书,看了很多遍源码整理的 一张图进阶 RocketMQ 图片链接,关于 RocketMQ 你只需要记住这张图!觉得不错的话,记得点赞关注哦。」
一张图进阶 RocketMQ 图片链接
【重要】视频在 B 站同步更新,欢迎围观,轻轻松松涨姿势。一张图进阶 RocketMQ-NameServer(视频版)
本文是《一张图进阶 RocketMQ》系列的第 2 篇,今天主要聊一聊 RocketMQ 集群元数据管理。因为 Producer、Consumer 和 Broker 都需要和 NameServer 交互,负责的三此君不得不先和大家唠一唠 NameServer 是何方神圣。
《RocketMQ 整体架构》中有说道 NameServer 是集群的元数据管理中心,那它到底管理了哪些元数据?我们来看看 NameServer 里面都穿了什么,看完了记得关注、转发、点赞、收藏哦。
img
集群元数据
简单来说,NameServer 负责集群元数据的增删改查。先不管这个增删改查是怎么实现的,我们甚至可以理解就是数据库的增删改查,但是我们一定要知道这些元数据都长什么样子。才能知道 Producer、Consumer 及 Broker 是如何根据这些数据进行消息收发的。
集群元数据
如图所示,二主二从的 Broker 集群相关的元数据信息,包括 topicQueueTable、BrokerAddrTable、ClusterAddrTable、brokerLiveInfo、FilterServer (暂时不用关注,图中未画出)。
HashMap<String topic, List<QueueData>> topicQueueTable
:Key 是 Topic 的名称,它存储了所有 Topic 的属性信息。Value 是个 QueueData 列表,长度等于这个 Topic 数据存储的 Master Broker 的个数,QueueData 里存储着 Broker 的名称、读写 queue 的数量、同步标识等。HashMap<String BrokerName, BrokerData> brokerAddrTable
:这个结构存储着一个 BrokerName 对应的属性信息,包括所属的 Cluster 名称,一个 Master Broker 和多个 Slave Broker 的地址信息HashMap<String ClusterName, Set<String BrokerName>> clusterAddrTable
:存储的是集群中 Cluster 的信息,就是一个 Cluster 名称对应一个由 BrokerName 组成的集合。HashMap<String BrokerAddr, BrokerLiveInfo> brokerLiveTable
:Key 是 BrokerAddr 对应着一台机器,BrokerLiveTable 存储的内容是这台 Broker 机器的实时状态,包括上次更新状态的时间戳,NameServer 会定期检查这个时间戳,超时没有更新就认为这个 Broker 无效了,将其从 Broker 列表里清除。HashMap<String BrokerAddr, List<String> FilterServer> filterServerTable
:Key 是 Broker 的地址,Value 是和这个 Broker 关联的多个 FilterServer 的地址。Filter Server 是过滤服务器,是 RocketMQ 的一种服务端过滤方式,一个 Broker 可以有一个或多个 Filter Server。
工作流程
然后我们来看一下 NameServer 简单的工作流程,其他角色会主动向 NameServer 上报状态,根据上报消息里的请求码做相应的处理,更新存储的对应信息。
image-20220612152922567
- Broker 接到创建 Topic 的请求后向 NameServer 发送注册信息,NameServer 收到注册信息后首先更新 Broker 信息,然后对每个 Master 角色的 Broker,创建一个 QueueData 对象。如果是新建 Topic,就是添加 QueueData 对象;如果是修改 Topic,就是把旧的 QueueData 删除,加入新的 QueueData。
- Broker 向 NameServer 发送的心跳会更新时间戳,NameServer 每 10 秒检查一次检查时间戳,检查到时间戳超过 2 分钟则认为 Broker 已失效,便会触发清理逻辑。
- 连接断开的事件也会触发状态更新,当 NameServer 和 Broker 的长连接断掉以后,onChannelDestroy 函数会被调用,把这个 Broker 的信息清理出去。
- Producer/Consumer 启动之后会和 NameServer 建立长连接,定时从 NameServer 获取路由信息保存到本地。消息的发送与拉取都会用到上面的数据。
为了让大家感受更真切,别以为都是三此君胡说八道,我们简简单单来看看源码:
总结
以上就是本文的全部内容,那么多数据,相信大家看的有点晕,三此君简单总结下:NameServer 通过 brokerLiveInfo 来维护存活的 Broker。Producer 会获取上面的路由信息,发送消息的时候指定发送到哪个 Topic,根据 Topic 可以从 topicQueueTable 选择一个 Broker,根据 BrokerName 可以从 BrokerAddrTable 获取到Broker IP 地址。有了 IP 地址 Producer 就可以和 Broker 建立连接将消息通过网络传递给 Broker。
最后,看懂的点赞,没看懂的收藏。来都来了,交个朋友,有任何问题,可以评论区留言或者私信。关注微信公众号:三此君。回复 mq,可以领取 RocketMQ 相关的所有资料。感谢观看,我们下期再见。
banner
参考文献
-
丁威, 周继锋. RocketMQ技术内幕:RocketMQ架构设计与实现原理. 机械工业出版社, 2019-01.
-
李伟. RocketMQ分布式消息中间件:核心原理与最佳实践. 电子工业出版社, 2020-08.
-
杨开元. RocketMQ实战与原理解析. 机械工业出版社, 2018-06.
转载请注明出处