一、架构设计
1.1 消息中间件设计思路
消息中间件的设计思路一般是基于主题订阅发布机制，即生产者发送某一个主题消息到服务器，消息服务器负责将消息持久化存储，消费者订阅感兴趣的主题，由服务器主动推送到消费者(Push模式)或消费者主动向消息服务器拉取(Pull模式)，从而实现生产者和消费者解耦。
1.2 NameServer 解决了什么
1.2.1 存在的问题
为了增加消息中间件的高可用性，避免消息服务器的单点故障导致整个系统瘫痪，通常会部署多台消息服务器共同承担消息的存储。那么问题随之而来：
- 消息生产者怎么知道消息要发送到哪台消息服务器呢？
- 若某一台消息服务器宕机了，消息生产者如何动态感知呢？
NameServer 就是为了解决以上问题设计的
1.2.2 解决方式
NameServer 就像一个寻址表，负责 broker 地址的记录：
- Broker 在启动时向所有存活的 NameServer 注册，NameServer 会记录当前这个 Broker 的 IP 地址等相关信息
- 消息生产者在发送消息前，先从 NameServer 获取 Broker 服务器地址列表，然后根据负载均衡算法从列表中选择一台服务器进行发送消息
- NameServer 和每一个注册的 Broekr 都保持长连接，每隔 30s 检测 Broker 是否存活，若检测到 Broker 宕机，则从路由注册表中删除。为了降低 NameServer 实现的复杂度，路由变化不会马上通知消息生产者，而是通过消息发送端的容错起止保证消息发送的可用性
- NameServer 的高可用是通过部署多台 NameServer 实现的，但 NameServer 服务器彼此之间不通讯，即各个 NameServer 服务器之间在某一时刻的数据并不完全相同，可是这对消息的发送不会造成任何影响 (因为已记录的 broker 仍能接收消息)