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集群的整个路由信息和用于客户端查询的队列信息,之后ProducerConsumer就可以通过NameServer拿到整个Broker集群的路由信息,从而进行消息的投递和消费。

此外,NameServer通常也是集群部署的方式,各个实例间不进行通信Broker向所有的NameServer都注册自己的路由信息,所以每个NameServer实例上都会保存一份完整的路由信息,当某个NameServer下线了,Broker仍然可以向其他NameServer发送路由信息,ProducerConsumer仍然可以获取到Broker的路由信息

BrokerServer:

Broker负责消息的存储、投递、查询及高可用的保证,为了实现这些功能,Broker包含了几个重要模块:

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

选择NameServer的理由浅析

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

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

从CAP理论的角度来分析:

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

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

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