RocketMQ是JAVA兄弟们常用的消息中间件,虽说常用,但对于RocketMQ架构经常忘记。究其原因就2点:忙于业务开发然后长时间不看则忘了、不理解架构设计的根本原因记不牢。本文用大白话描述架构设计过程,牢记RocketMQ架构。
首先,在记框架的原理和架构时,要先把握全局的脉络,在思考为什么这么设计,最后才是思考细节,这样才能记得牢。本文通过层层追问的方式,一步步解说RocketMQ架构设计的原因。
答:起码要设计3个角色:
答:这里借鉴实际生活中的案例,比如物流公司在发快递时,发往同一个城市的快递,肯定安排在一起,然后用同一批货车运往那个城市,这样整个物流体系运转是最高效的。这里就用到了聚类的方式,让相似的事物聚到一起。
同样的,在设计怎么存储消息时,也用到聚类的概念,我们把相同类型的消息,放到一个逻辑空间里,这个逻辑空间就是主题Topic。
答:Topic的内部肯定是一个个的消息对象,那这些消息对象是以什么数据结构存在一起的呢?先发的消息,尽量要保证先被消费到,这里就用到了先进先出的数据结构-队列,这就是消息队列MessageQueue。所以,Topic内部是由MessageQueue组成,消息队列内部存放着一个个的消息对象。
答:既然是RocketMQ的核心,肯定要保证高可用不能挂,所以RocketMQ 会部署多台 Broker 组成一个集群对外提供服务。
答:我们要学习“鸡蛋不能放在一个篮子里”的思想。既然是要存大量的消息,又有多台Broker,为了分担单台机器性能压力、分担存储容量压力、保证数据容灾,所以将不同的Topic存储到不同的Broker里。
还是按照上面物流的例子说明,比如从北京发往南京的快递,肯定用同一批货车运送,快递少则用一辆货车,快递多则用多辆货车,快递被划分到了多个货车上。同样的,RocketMQ里的Topic也是分散存储在多台 Broker 上的,每台Broker上存储的消息内容是不同的。
答:上面我们提到,Topic实际上是一个个队列的集合,那只需要将队列分散存储到不同的Broker上就行了。
答:这时候就会用到Broker的主-从架构,Broker按角色分为Master和Slave,主从之间会定期地进行数据同步。Master 负责响应客户端的读写请求、存储消息、处理消费者请求等,而 Slave 只负责同步 Master 的数据。
答:RocketMQ引入了NameServer的概念,NameServer相当于大管家,RocketMQ里的所有基础信息它都知道。NameServer 存储了RocketMQ 集群的元数据。NameServer 中存放的元数据主要有:
答:类似古时候某个人去府里当差,当差之前要把自己的所有信息登记在册。同样的,Broker、Producer、Consumer在启动时也会将数据注册到 NameServer。
Broker 在启动时会将自己注册到 NameServer 上,通过心跳持续更新元数据。同样的,Producer、Consumer也会和NameServer建立连接、动态交互集群中的数据,这样即方便上报自己的信息和也方便获取集群里的其他信息。
至此,RocketMQ的架构图已经成型,每一个部件这么设计的原因也很清晰。
RocketMQ里的核心角色有4个:Broker、Producer、Consumer、NameServer,消息存储的核心对象有2个:Topic、MessageQueue。
为了保证数据不丢失 和 数据不倾斜,同一个Topic里的MessageQueue会分散存储在不同的Broker里。