🍊 Java学习：Java从入门到精通总结

🍊 深入浅出RocketMQ设计思想：深入浅出RocketMQ设计思想

🍊 绝对不一样的职场干货：大厂最佳实践经验指南


📆 最近更新：2022年11月18日

🍊 个人简介：通信工程本硕💪、Java程序员🌕。做过科研paper，发过专利，优秀的程序员不应该只是CRUD

🍊 点赞 👍 收藏 ⭐留言 📝 都是我最大的动力！

文章目录

• NameServer简介
• 选择NameServer的理由浅析

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包含了几个重要模块：

1. 处理来自client端的请求
2. 管理客户端（Producer / Consumer）及维护Consumer的Topic订阅信息
3. 提供方便简单的API接口将消息存储到硬盘和查询功能
4. 提供主从Broker之间的数据同步功能
5. 根据特定的key对Broker中的消息进行检索，以提供消息的快速查询功能

选择NameServer的理由浅析

之前说过，RocketMQ设计之初参考的是Kafka，而Kafka是用的ZooKeeper作为自己的注册中心，提供了Master选举、分布式锁、数据发布订阅等等功能。

在RocketMQ的初期版本，确实也用的是ZooKeeper，之所以更换成自己开发的NameServer，是因为RocketMQ只需要一个轻量级的元数据服务器即可，只需要保证最终一致性而不需要ZooKeeper这样的强一致性解决方案，从而从整体上减少了维护成本。

从CAP理论的角度来分析：

1. 一致性： NameServer集群里的实例之间不互相通信，意味着在同一时刻，不同实例上维护的元数据可能是不同的，客户端获取到的数据也可能是不一致的。

2. 可用性： 只要不是所有NameServer挂掉，其他情况下都可用。

3. 分区容错： 对于分布式架构，出现网络分区是不可避免的，只要保证部分NameServer可达，就能够获取到数据。例如：可以将NameServer部署在不同的机房里实现跨机房灾备。