九个问答牢记RocketMQ架构

逃离我推掉我的手 2024-02-05 19:39 33阅读 0赞

RocketMQ是Java兄弟们常用的消息中间件，虽说常用，但对于RocketMQ架构经常忘记。究其原因就2点：忙于业务开发然后长时间不看则忘了、不理解架构设计的根本原因记不牢。本文用大白话描述架构设计过程，牢记RocketMQ架构。

![ef13718b2f2425c6c36a575984ec394a.png][]

### **一、架构的思考过程** ###

首先，在记框架的原理和架构时，要先把握全局的脉络，在思考为什么这么设计，最后才是思考细节，这样才能记得牢。本文通过层层追问的方式，一步步解说RocketMQ架构设计的原因。

#### **1.基本形态** ####

##### **(1) 如果你是RocketMQ的开发者，让你来设计一个消息中间件，你会设计哪些角色？** #####

答：起码要设计3个角色：

*  消息中转站：Broker，Broker是核心，负责：接受消息、存储消息、处理消费者的消费请求、备份容灾等。
 *  生产者：Producer，生产消息然后投递到Broker。
 *  消费者：Consumer，从Broker中消费消息。

![78b5166b3bdd6f9993fca4f922da1f85.png][]

#### **2.消息怎么存** ####

##### **(2) 有了基本形态后，我们知道，具体的消息肯定是存在Broker里，那消息在Broker里应该怎么存储呢？** #####

答：这里借鉴实际生活中的案例，比如物流公司在发快递时，发往同一个城市的快递，肯定安排在一起，然后用同一批货车运往那个城市，这样整个物流体系运转是最高效的。这里就用到了聚类的方式，让相似的事物聚到一起。

同样的，在设计怎么存储消息时，也用到聚类的概念，我们把相同类型的消息，放到一个逻辑空间里，这个逻辑空间就是主题Topic。

![69d366a2ffed5c2a5ceb2d0b333d78c3.png][]

##### **(3) 那Topic的内部又是什么结构呢？** #####

答：Topic的内部肯定是一个个的消息对象，那这些消息对象是以什么数据结构存在一起的呢？先发的消息，尽量要保证先被消费到，这里就用到了先进先出的数据结构-队列，这就是消息队列MessageQueue。所以，Topic内部是由MessageQueue组成，消息队列内部存放着一个个的消息对象。

![5d4554b5143fb34e41b7b51a33ec32e8.png][]

#### **3.引入集群** ####

##### **(4) 我们知道Broker是RocketMQ的核心，这么重要的核心挂了怎么办？** #####

答：既然是RocketMQ的核心，肯定要保证高可用不能挂，所以RocketMQ 会部署多台 Broker 组成一个集群对外提供服务。

![70099f14d35bde0aec0c4b6a80745965.png][]

#### **4.再说消息怎么存** ####

##### **(5) RocketMQ为了保障高可用，会部署多台Broker组成集群，那么集群场景下有多台机器，Topic怎么存呢？** #####

答：我们要学习“鸡蛋不能放在一个篮子里”的思想。既然是要存大量的消息，又有多台Broker，为了分担单台机器性能压力、分担存储容量压力、保证数据容灾，所以将不同的Topic存储到不同的Broker里。

还是按照上面物流的例子说明，比如从北京发往南京的快递，肯定用同一批货车运送，快递少则用一辆货车，快递多则用多辆货车，快递被划分到了多个货车上。同样的，RocketMQ里的Topic也是分散存储在多台 Broker 上的，每台Broker上存储的消息内容是不同的。

##### **(6) 如果不同的Topic存储在不同的Broker里，可能某个topic数据太大了，出现数据倾斜直接干爆某个Broker怎么办？** #####

答：上面我们提到，Topic实际上是一个个队列的集合，那只需要将队列分散存储到不同的Broker上就行了。

![c95bee0ca92e9dfe332aab7a6d96cf36.png][]

##### **(7) 如果不同的Topic分散存储在不同的Broker里，还是有数据丢失的风险，只不过某个topic丢失的数据变小而已，这种情况的数据容灾备份怎么做呢？** #####

答：这时候就会用到Broker的主-从架构，Broker按角色分为Master和Slave，主从之间会定期地进行数据同步。Master 负责响应客户端的读写请求、存储消息、处理消费者请求等，而 Slave 只负责同步 Master 的数据。

![5bd6fcf41af9d61e4a0f7099a4884fd3.png][]

#### **5.说说NameServer** ####

##### **(8) Broker既然是集群，那生产者在投递消息时，总得知道有哪些Broker吧，总得知道要往哪个Broker里投递消息吧，这又要怎么做呢？** #####

答：RocketMQ引入了NameServer的概念，NameServer相当于大管家，RocketMQ里的所有基础信息它都知道。NameServer 存储了RocketMQ 集群的元数据。NameServer 中存放的元数据主要有：

*  集群里都有哪些Broker？
 *  有哪些生产者？
 *  有哪些消费者？
 *  集群里都有哪些 Topic？
 *  这些 Topic 的消息队列分别存在哪些 Broker 上？

##### **(9) 那Nameserver如何知道这些消息呢？** #####

答：类似古时候某个人去府里当差，当差之前要把自己的所有信息登记在册。同样的，Broker、Producer、Consumer在启动时也会将数据注册到 NameServer。

Broker 在启动时会将自己注册到 NameServer 上，通过心跳持续更新元数据。同样的，Producer、Consumer也会和NameServer建立连接、动态交互集群中的数据，这样即方便上报自己的信息和也方便获取集群里的其他信息。

![fea222208f54f5c91c5fdc1874b562f1.png][]

至此，RocketMQ的架构图已经成型，每一个部件这么设计的原因也很清晰。

### **二、总结** ###

RocketMQ里的核心角色有4个：Broker、Producer、Consumer、NameServer，消息存储的核心对象有2个：Topic、MessageQueue。

为了保证数据不丢失 和 数据不倾斜，同一个Topic里的MessageQueue会分散存储在不同的Broker里。

[ef13718b2f2425c6c36a575984ec394a.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/30/d887eee8eea446319acb16ab434efa2b.png
[78b5166b3bdd6f9993fca4f922da1f85.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/30/1efbdfcd55244293b36327a7b8d3f9df.png
[69d366a2ffed5c2a5ceb2d0b333d78c3.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/30/003e3b43621d48a58f9225fac81ee6f4.png
[5d4554b5143fb34e41b7b51a33ec32e8.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/30/87b3d195548a4c598d66c8d5b02a1599.png
[70099f14d35bde0aec0c4b6a80745965.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/30/2f9c9105649b4366b146d2bbd84bcc83.png
[c95bee0ca92e9dfe332aab7a6d96cf36.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/30/d8f946ec9108478e927d04a9534aa269.png
[5bd6fcf41af9d61e4a0f7099a4884fd3.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/30/bc00a7e3b3a74f729ab43605ae721312.png
[fea222208f54f5c91c5fdc1874b562f1.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/30/146c1870dd1349a9afbd1fcc95c47c0e.png