RocketMQ基础架构介绍

在日常处理高并发的业务需求时，为了优化执行效率，我们会将一个业务拆分成几个部分，通过消息队列异步执行任务来提高业务执行效率，而消息队列除了我们知道的Kafka、RabbitMQ等，阿里研发的RocketMQ也是一款非常优秀的中间件，它结合了事务消息、消息过滤、延时消息确认等优秀特性，本文旨在由浅入深介绍RocketMQ的基础架构

基础消息队列模型-Broker

基础的消息队列一般都会满足发布-订阅模式，即生产者生产消息后将任务放入消息队列中，之后消费者会从消费队列中取出任务，而Broker组件作为RocketMQ的核心中的核心，它主要负责完成接收生产者消息、持久化消息、处理消费者的消费请求等：

Broker在RocketMQ中的作用

但是在大量的请求下，只有一个Broker如果挂掉肯定不行，因此可以多部署几台Broker合作处理消息，可以将发送来的消息平均分配到各个Broker，这样将各个Broker分散到多台服务器上即可：

将消息分配到多个Broker中

但是这样分配后，如果某个订单业务只需要与订单相关的任务结果，那么该如何快速高效返回任务结果呢，为此，RocketMQ中引入了Topic概念

RocketMQ的消息分配主题-Topic

当我们将消息发送给Broker进行持久化以及处理时，我们可以给当前发送消息指定一个Topic（主题），指定主题后，该条消息就会被发送到Broker的指定Topic队列中，而如果某个Topic消息过多，导致一个Broker难以承载，我们就可以将该Topic分散为多个队列放到多个Broker上进行处理：

每个Broker中分散有多个Topic消息主题

通过这样分配后，当某个业务需要Topic-A的消息数据时，只需要从这些Broker中获取对应Topic-A的数据即可，能够加快查找效率，同时也能够简化分配，但是这里的Topic是抽象概念，在RocketMQ消息队列模型中，Topic只是一个概念，而将属于某个Topic的消息真正放入Broker，是靠接下来介绍的MessageQueue完成的

Broker中Topic消息的组织形式-MessageQueue

当我们将某个Topic的消息分散为多份放到多个Broker中后，为了方便组织这些Topic的消息内容，我们将属于某个主题的消息内容放入MessageQueue中，也就是将TopicA的内容分为queue0、queue1与queue2等分散到不同Broker上面，这样做不仅能够最大程度容灾，同时也能均匀分散数据，防止数据倾斜：

通过MessageQueue组织Topic消息

值得注意的是，虽然我们会将消息放入MessageQueue中，但是最终消息还是会被持久化到磁盘中，确保不会丢失

虽然我们通过使用MessageQueue解决了数据倾斜的问题，但是如果某个Broker挂了，那么这个Broker中的队列消息不还是全部丢失了？那么这时候该怎么办呢

主从架构解决数据丢失

为了解决这一点，研发人员借鉴MySQL、Redis的主从架构模式，也引入了Broker主从架构模式，主节点（Master Broker）负责数据的读写请求、存储消息等，而从节点（Slave Broker）只负责同步主节点的消息，以此保证数据不会丢失：

主从Broker同步

而在4.5.0版本之前，如果主节点宕机，更换从节点的方式还是人工确认，在4.5.0版本后，RocketMQ提供了高可用集群Dledger的实现，它能够满足在主节点宕机的情况下，通过一致性Raft算法自动选举切换主节点

但是在多个Broker工作的情况下，如果此时某个Producer前来发送消息，那么它如何确定发送到哪个Broker中、获取对应Broker的发送地址呢？

组织管理RocketMQ的元信息-NameServer

借鉴微服务的注册中心思想，在RocketMQ中引入了NameServer实现：NameServer会存储对应的Topic信息、某个Topic存储到哪个MessageQueue上、活跃的Broker等信息，这样当某个Producer发送消息时，会通过NameServer选择一个相对空闲的Broker来处理持久化消息，那么NameServer中的信息如何获取呢？

类比注册中心，每个Broker集群启动时，会将本集群中的所有信息发送并存储到NameServer中，同时Producer、Consumer、Broker都会通过心跳续期机制动态，实时将元信息更新到NameServer中，这样就能确保NameServer中存储的都是最新信息进行节点发现与寻找

而仅仅依靠一个NameServer来注册信息肯定是不行的，因此NameServer也需要有几个来确保如果某个NameServer挂了，不会影响整体的服务

至此，整个Broker集群的架构便演变到了下图，也就是RocketMQ的最终形式：

RocketMQ的基础架构

至此，通过Broker集群将消息分布式地存储到多台机器上，引入抽象概念Topic将消息进行分类，使用MessageQueue组织分配Topic信息，将Broker集群信息注册到NameServer集群上面等一系列措施，我们便完成了对于RocketMQ架构的介绍与设计，本文也到此结束了，希望对你有所帮助！！！