共计 2465 个字符，预计需要花费 7 分钟才能阅读完成。
前言
三此君看了好几本书，看了很多遍源码整顿的 一张图进阶 RocketMQ 图片，对于 RocketMQ 你只须要记住这张图！感觉不错的话，记得点赞关注哦。
【重要】视频在 B 站同步更新，欢送围观，轻轻松松涨姿态。一张图进阶 RocketMQ-NameServer（视频版）
https://www.bilibili.com/vide…
本文是《一张图进阶 RocketMQ》系列的第 2 篇，明天次要聊一聊 RocketMQ 集群元数据管理。因为 Producer、Consumer 和 Broker 都须要和 NameServer 交互，负责的三此君不得不先和大家唠一唠 NameServer 是何方神圣。
《RocketMQ 整体架构》中有说道 NameServer 是集群的元数据管理核心，那它到底治理了哪些元数据？咱们来看看 NameServer 外面都穿了什么，看完了记得关注、转发、点赞、珍藏哦。
集群元数据
简略来说，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 上报状态，依据上报音讯里的申请码做相应的解决，更新存储的对应信息。
- 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 相干的所有材料。感激观看，咱们下期再见。
参考文献
- RocketMQ 官网文档
- RocketMQ 源码
- 丁威, 周继锋. RocketMQ 技术底细：RocketMQ 架构设计与实现原理. 机械工业出版社, 2019-01.
- 李伟. RocketMQ 分布式消息中间件：外围原理与最佳实际. 电子工业出版社, 2020-08.
- 杨开元. RocketMQ 实战与原理解析. 机械工业出版社, 2018-06.
转载请注明出处
