九个问答牢记 RocketMQ 架构-51CTO.COM

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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