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
包含了几个重要模块:
- 处理来自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
部署在不同的机房里实现跨机房灾备。