九个问答牢记RocketMQ架构

发布时间:2023年12月27日

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怎么办?

答:上面我们提到,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 中存放的元数据主要有:

  • 集群里都有哪些Broker?
  • 有哪些生产者?
  • 有哪些消费者?
  • 集群里都有哪些 Topic?
  • 这些 Topic 的消息队列分别存在哪些 Broker 上?
(9) 那Nameserver如何知道这些消息呢?

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

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

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

二、总结

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

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

文章来源:https://blog.csdn.net/pantouyuchiyu/article/details/135241752
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。