前言
「三此君看了好几本书，看了很多遍源码整理的 一张图进阶 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.
转载请注明出处