九个问答牢记RocketMQ架构 _RocketMQ

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

文章插图
一、架构的思考过程首先，在记框架的原理和架构时，要先把握全局的脉络，在思考为什么这么设计，最后才是思考细节，这样才能记得牢。本文通过层层追问的方式，一步步解说RocketMQ架构设计的原因。
1.基本形态(1) 如果你是RocketMQ的开发者，让你来设计一个消息中间件，你会设计哪些角色？答：起码要设计3个角色：

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

文章插图
2.消息怎么存(2) 有了基本形态后，我们知道，具体的消息肯定是存在Broker里，那消息在Broker里应该怎么存储呢？答：这里借鉴实际生活中的案例，比如物流公司在发快递时，发往同一个城市的快递，肯定安排在一起，然后用同一批货车运往那个城市，这样整个物流体系运转是最高效的。这里就用到了聚类的方式，让相似的事物聚到一起。
同样的，在设计怎么存储消息时，也用到聚类的概念，我们把相同类型的消息，放到一个逻辑空间里，这个逻辑空间就是主题Topic 。

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

文章插图
3.引入集群(4) 我们知道Broker是RocketMQ的核心，这么重要的核心挂了怎么办？答：既然是RocketMQ的核心，肯定要保证高可用不能挂，所以RocketMQ 会部署多台 Broker 组成一个集群对外提供服务。

文章插图
4.再说消息怎么存(5) RocketMQ为了保障高可用，会部署多台Broker组成集群，那么集群场景下有多台机器，Topic怎么存呢？答：我们要学习“鸡蛋不能放在一个篮子里”的思想。既然是要存大量的消息，又有多台Broker，为了分担单台机器性能压力、分担存储容量压力、保证数据容灾，所以将不同的Topic存储到不同的Broker里。
还是按照上面物流的例子说明，比如从北京发往南京的快递，肯定用同一批货车运送，快递少则用一辆货车，快递多则用多辆货车，快递被划分到了多个货车上。同样的， RocketMQ里的Topic也是分散存储在多台 Broker 上的，每台Broker上存储的消息内容是不同的。
(6) 如果不同的Topic存储在不同的Broker里，可能某个topic数据太大了，出现数据倾斜直接干爆某个Broker怎么办？【九个问答牢记RocketMQ架构】答：上面我们提到，Topic实际上是一个个队列的集合，那只需要将队列分散存储到不同的Broker上就行了。

文章插图
(7) 如果不同的Topic分散存储在不同的Broker里，还是有数据丢失的风险，只不过某个topic丢失的数据变小而已，这种情况的数据容灾备份怎么做呢？答：这时候就会用到Broker的主-从架构，Broker按角色分为Master和Slave ，主从之间会定期地进行数据同步。Master 负责响应客户端的读写请求、存储消息、处理消费者请求等，而 Slave 只负责同步 Master 的数据。

文章插图
5.说说NameServer(8) Broker既然是集群，那生产者在投递消息时，总得知道有哪些Broker吧，总得知道要往哪个Broker里投递消息吧，这又要怎么做呢？答：RocketMQ引入了NameServer的概念，NameServer相当于大管家，RocketMQ里的所有基础信息它都知道。NameServer 存储了RocketMQ 集群的元数据。NameServer 中存放的元数据主要有：