所有 Broker 的 BrokerID 和 Address 的对应关系，是个 Map，Address 为 IP+端口
同一个 Broker Name 下，为什么会有多个地址信息已经在上个步骤解答过，不在此赘述。
Broker 的数据维护主要有两个方面：
该 Broker 数据在 brokerAddrTable 中是否存在
brokerAddrTable 中维护的数据不能有重复的地址信息
第一个过于基础简单，就不再赘述。我们重点看第二个点，我们知道会有多个 Broker 地址，存在一个 Map 中，因为 Broker 是基于主从架构。那不知道你有没有想过，NameServer 如何区分 主 和 从 的呢？
答案是通过 Map 的 Key，如果是 0 则代表是 Master 节点，1 则代表 Slave 节点，因为 RocketMQ 自己实现的 Broker 主从架构是一主一从，而一主多从则是由 RocketMQ 4.5 之后加入的 Dleger 实现的，暂时先不讨论。区分的逻辑如下图：
那什么时候会出现重复呢？
答案是主从切换
举个例子，假设某个 Slave Broker 的 Address 为 192.168.1.101:8081 ，且已经注册。此时brokerAddrs 中已经有一个key: 1 value: 192.168.1.101:8081 记录了。
当集群中的 Master 宕机之后，会进行故障恢复，假设选中了上面这个 Broker 为新的 Master，在进行注册的时候会发现，brokerAddrs 中已经有一个同样的 Address 了，只是 Key 不同。但是由于它们从本质上来说就是同一台机器，如果不将 key 为1，也就是角色为 Slave 的记录去掉，就会造成数据一致性的问题。
简单总结一下来说，同一个 Adreess，在 brokerAddrs 中只能存在一个。感兴趣的可以看一下源码，其实跟上面文字描述的逻辑是一样的。
去除了重复的 Address 数据之后，就会将本次注册的 Broker 的数据注册进 brokerAddrs 中。
维护 MessageQueue 的数据这里主要是根据 Broker 的数据更新其 MessageQueue 相关的数据。接下来，我们详细解析一下 Message Queue 的维护流程，同样会给出源码和流程图，两部分等价，可选择性观看。
当 Master 节点来注册时，如果是首次注册或者数据有更新，便会调用一个方法createAndUpdateQueueData去维护 MessageQueue 相关的数据。这里对数据是否更新的判断，是基于 DataVersion 的，代表 Broker 数据的版本。
此后通过 Topic 的 Name 拿到对应的 MessageQueue 的列表，这里可能会有点疑问，一个 Topic 难道不应该只有一个对 MessageQueue 相关的配置吗，为什么这里拿到的是个列表？
小了，格局小了
Topic 是个逻辑上的概念，一个 Topic 的 MessageQueue 会分布在不同的 Broker 上，所有这里是个列表。
更新的流程如上图，拿到了 MessageQueue 的列表之后，会和本次注册的 Broker 中的 MessageQueue 数据做一个对比，如果发现不同就进行全量的替换，没什么其他的复杂对比逻辑。源码等同上图，感兴趣的可以自行查看。
到这里，MessageQueue 相关的逻辑就处理完了，接下来 NameServer 会再去更新 brokerLiveTable 中的数据，这里存放了当前正在活跃的所有 Broker。这块的作用后续会讲。
NameServer 启动流程上面通过了解注册 Broker的整个流程，对整个 NameServer 的架构有了个大概的了解，接下来再从整体视角来看一下 NameServer。
整体的流程上面这张图已经给出来了，就不放源码了，意义不大。
这里说一下扫描不再活跃的Broker，这个后台线程会每 10秒 钟执行一次，这里会对上文提到的 brokerLiveTable 进行遍历处理，因为这里面维护了所有的正在活跃的 Broker。
如果某个 Broker 超过了 120秒 没有发送心跳给 NameServer，就会将其从 brokerLiveTable 中移除。
NameServer 可处理的操作上面简单了解了 注册 Broker 的流程，实际上 NameServer 还支持很多其他的操作，这里就不再这里列出来了，看了没有意义，感兴趣的可以自己去网上找，一大堆的资料。而且 Register Broker 这个操作中所涉及到源码中的数据结构，其他的操作都会用到，所以了解了 Register Broker 之后，再去阅读其他操作的源码会非常的顺。