RocketMQ原理

(1)RocketMQ整体架构

RocketMQ整体架构包含了4中角色:

  • NameServer
  • Broker
  • Producer
  • Consumer

其中NameServer主要用于管理整个集群的元数据以及对集群进行管理的。

Broker相当于单个节点负责数据的读写的,而Producer就是负责生产消息后写入Broker的,Consumer则是从Broker来消费消息。

而且Broker在部署的时候,一般是分为主备角色的。也就是说,每个Broker都部署一个Master角色在一台机器上,然后另外会部署一个Slave角色在另外一台机器上。

这样如果某个Broker Master挂了,他的Broker Slave就可以接替继续工作,保证了高可用。

下图阐述了RocketMQ的整体架构原理:

RocketMQ原理

(2)RocketMQ工作流程

首先需要先启动NameServer,接着启动Broker

Broker启动之后就会跟NameServer建立长连接,每隔一段时间发送心跳包过去

心跳包里需要包含自己当前存储的数据信息,让NameServer感知到各个Broker的情况,如下图:

RocketMQ原理

创建Topic的时候决定Topic的数据会放在哪个Broker上。

每个Broker在进行心跳的时候,就可以上报自己当前存储的Topic相关的数据给NameServer知道。

而NameServer就保存了整个集群的元数据,知道每个Topic当前数据保存在哪些Broker上,如下图:

RocketMQ原理

Producer在生产消息到Topic的时候,先得找NameServer问一下Topic存放在哪些Broker上,然后就可以跟那些Broker建立连接发送消息过去了。

Consumer要从Topic消费消息,也会找NameServer问一下可以从哪些Broker上消费消息,接着同样会跟Broker建立连接并且开始消费消息,如下图。

RocketMQ原理

(3)NameServer原理分析

NameServer一般是集群化部署,各个机器上部署的NameServer会相互同步收集到的元数据,保证各个NameServer上包含的集群元数据都是相同的。这样的架构可以保证即使任何一个NameServer宕机了也不要紧。

NameServer主要责任就是管理Broker的心跳,如果一段时间内没有心跳,则认为那个Broker已经宕机了,此时要触发对应的Slave切换为Master保证高可用。

此外,NameServer还要负责管理和维护集群元数据,比如有哪些Topic,每个Topic在哪些Broker上。

NameServer承受的请求压力是很小的,因为心跳和拉取元数据,其实是很低频的行为,所以一般部署两三台机器就足够了。

但是需要注意的是 ,如果集群里维护了几十万个,甚至几百万个Topic,会导致Broker每次心跳上报Topic数据时,带上几十万个Topic的数据信息,可能多达几十MB,那会导致心跳时网络负载过重。

(4)分布式架构分析

再说说Topic,每个Topic都由很多个队列组成,一个队列代表了这个Topic的部分数据,然后这个Topic的多个队列会均匀分散在多个Broker上。

比如说Topic有6个队列,对应三台Broker,那么每个Broker上就可以放2个队列的数据。

这样就可以做到每个Topic的数据都可以分布式存储在集群中的多台Broker上,形成了分布式的存储架构,这样就可以利用多台机器的资源来存储数据

同时,可以利用多台机器的资源来应对高并发的请求,因为对一个Topic的读写请求,就会均匀的落到多台Broker机器上去了。

如下图所示,可以看到数据分布式存储的架构。

RocketMQ原理

(5)Broker原理分析

Broker主要就两点:负责接收Producer写入的消息,同时提供消息给Consumer来读取。

写入消息时,Broker可以实现高并发高性能的写入。

这个主要采用的是对磁盘文件进行顺序写的方式,磁盘顺序写的性能是很高的,几乎跟内存随机读写的性能差不多。

另外,就是优先把数据写入os page cahce,也就是操作系统管理的缓存中。

写操作系统的内存缓存,那性能就更高了,不需要每次都直接写入物理磁盘中。

读取消息时,Broker也是主要基于os page cahce读取消息,也就是优先从操作系统管理的内存缓存中读取数据,提供给Consumer来消费。因为是优先读内存,所以同样性能也是很高的。

通过这种架构,Broker就可以保证高并发以及高性能。

另外,Broker还实现了高可用的架构。也就是说每个Broker Master都会把自己接收到的数据同步给Broker Slave,实现每个Broker上的数据备份。

如果Broker Master宕机了,会切换Broker Slave对外提供服务,保证了高可用的架构。

(6)Consumer原理分析

如果我们部署了Consumer在多台机器上,默认也会把Topic下的多个队列的数据均匀的分配给各个Consumer实例来进行消费。

比如Topic下一共6个队列,假设部署了3个Consumer实例,此时每个Consumer实例就会消费2个队列的数据,如下图:

RocketMQ原理

(7)总结

对于任何一个消息系统,对他的原理进行研究的时候,都应该关注几点:

  • 集群架构(元数据如何管理、集群如何管理)
  • 数据模型(Topic、队列等概念)
  • 分布式架构(消息如何分布式存储)
  • 消息写入以及读取的原理
  • 高可用架构(如何进行数据冗余)
  • 客户端原理

把这些弄明白之后,才算对一个消息系统有了一定的了解,才能开始尝试把这个消息系统应用于自己公司的生产项目中。

 

 

上一篇:你懂RocketMQ 的架构原理吗?


下一篇:RocketMQ避坑指南:你部署的RocketMQ集群真的是高可用?