一起养成写作习惯！这是我参与「掘金日新计划 · 4 月更文挑战」的第20天，点击查看活动详情。
RocketMQ作为分布式的消息中间件，在设计的时候充分参考了同类型产品Kafka的架构。
在Kafka的实现里，服务注册与发现功能是用ZooKeeper实现的，而RocketMQ使用的是自己开发的服务注册中心NameServer，进一步地提高了服务的可用性。
NameServer简介
再次回看一下
RocketMQ的集群架构，里面的注册中心就是NameServer，它是一个轻量级的Topic路由注册中心，角色类似于Dubbo里的ZooKeeper，支持Broker的动态注册与服务发现，主要实现两个功能：
-
Broker管理 -
路由信息管理
Broker管理：
NameServer接收Broker集群的注册信息并保存下来作为路由信息。此外，还会提供心跳检测机制，监测Broker是否“存活”。
路由信息管理：
NameServer会保存关于Broker集群的整个路由信息和用于客户端查询的队列信息，之后Producer和Consumer就可以通过NameServer拿到整个Broker集群的路由信息，从而进行消息的投递和消费。
此外，NameServer通常也是集群部署的方式，各个实例间不进行通信，Broker向所有的NameServer都注册自己的路由信息，所以每个NameServer实例上都会保存一份完整的路由信息，当某个NameServer下线了，Broker仍然可以向其他NameServer发送路由信息，Producer和Consumer仍然可以获取到Broker的路由信息
BrokerServer：
Broker负责消息的存储、投递、查询及高可用的保证，为了实现这些功能，Broker包含了几个重要模块：
- 处理来自client端的请求
- 管理客户端（
Producer/Consumer）及维护Consumer的Topic订阅信息 - 提供方便简单的API接口将消息存储到硬盘和查询功能
- 提供主从
Broker之间的数据同步功能 - 根据特定的
key对Broker中的消息进行检索，以提供消息的快速查询功能
选择NameServer的理由浅析
之前说过，RocketMQ设计之初参考的是Kafka，而Kafka是用的ZooKeeper作为自己的注册中心，提供了Master选举、分布式锁、数据发布订阅等等功能。
在RocketMQ的初期版本，确实也用的是ZooKeeper，之所以更换成自己开发的NameServer，是因为RocketMQ只需要一个轻量级的元数据服务器即可，只需要保证最终一致性而不需要ZooKeeper这样的强一致性解决方案，从而从整体上减少了维护成本。
从CAP理论的角度来分析：
1. 一致性：
NameServer集群里的实例之间不互相通信，意味着在同一时刻，不同实例上维护的元数据可能是不同的，客户端获取到的数据也可能是不一致的。
2. 可用性： 只要不是所有NameServer挂掉，其他情况下都可用。
3. 分区容错： 对于分布式架构，出现网络分区是不可避免的，只要保证部分NameServer可达，就能够获取到数据。例如：可以将NameServer部署在不同的机房里实现跨机房灾备。
