文章目录


RocketMQ-初体验RocketMQ(05)_RocketMQ架构解读_持久化


Rocketmq整体架构

​RocketMQ-初体验RocketMQ(01)_RocketMQ初体验​​​中 对 ​​RocketMQ 架构图​​做了一个大体的介绍

接下来,我们再细说一下RocketMQ的架构

RocketMQ-初体验RocketMQ(05)_RocketMQ架构解读_数据_02

如上图

整体由4部分组成

  • namesrv
  • broker
  • producer
  • consumer

namesrv

当broker服务启动后,会向namesrv注册信息,比如broker中的 主题、消费偏移量、队列、ip、端口等,由broker的心跳发送到namesrv。

broker cluster中的每一个节点都会注册到namesrv上。

比如 你有4个broker节点,2个namesrv,那么注册如下

RocketMQ-初体验RocketMQ(05)_RocketMQ架构解读_偏移量_03

这种情况的话,即使一个namesrv节点挂了,剩下的一个namesrv节点仍然包含所有的broker信息。

需要注意的是: namesrv是无状态的, namesrv之间不会相互通信,跟zk是不一样的。一个namesrv挂了,不会影响另外一个namesrv,这俩namesrv是没有关联的。


broker

来南下每个broker的组成吧

RocketMQ-初体验RocketMQ(05)_RocketMQ架构解读_Rocketmq整体架构_04

每一个broker节点 ,储存消息,都会对应一个commitlog , commitlog 负责存储真实的消息的内容。

broker中的每个topic , 如果不设置的话, 默认创建4个队列, 队列编号 0 , 1 ,2 , 3. 每个队列都会对应一个持久化文件 。

当producer向broker中的topic发送消息的时候, 如果发现队列没有创建持久化文件,会自动创建。 然后该队列的持久化信息都会存放在该持久化文件中。

每个broker下面会创建一个consumerOffset.json文件. 这个json文件用来记录当前你消费节点已经消费的数据位置,即消费的偏移量。这个也是需要持久化的。 这个偏移量的来源 是 consumer 来上报的。(如下图)

RocketMQ-初体验RocketMQ(05)_RocketMQ架构解读_偏移量_05

consumer从broker中拉取消息后,要进行消费,消费了多多少消息,要把消费这些对应的这些偏移量上报到broker上去。 主要是为了什么呢? ---->最大可能的避免消息重复的推送。


producer & consumer

Q: producer & consumer 到底选择跟哪个broker去连接,去消费哪个broker中的消息?

A: producer & consumer也是无状态的,每一个producer之间 ,每一个consumer之间都不会通信, ​每个producer和consumer内部都有自己的一套负载均衡的算法 ,默认的选择策略: 已发送的消息数量对queuecount取mod .

消费者的两种消费模式主要有两种: 推跟拉

  • 拉取式消费(Pull Consumer):Consumer消费的一种类型,应用通常主动调用Consumer的拉消息方法从Broker服务器拉消息、主动权由应用控制。一旦获取了批量消息,应用就会启动消费过程。

  • 推动式消费(Push Consumer):Consumer消费的一种类型,该模式下Broker收到数据后会主动推送给消费端,该消费模式一般实时性较高。

pull的方式,由客户端来主动获取,通过定时任务或者需要的时候从broker端获取,这种方式用的比较少。 如果消息量比较少, 堆积也不会太多,对安全性要求不高的应用,可以考虑。

与此对应的另外一种push方式:

push的方式,在RocketMQ中其实也是基于pull模式的一个深度封装,consumer对broker进行一个长轮询,一直监听broker中的数据,就好像是broker主动推送给consumer似的。


通信方式

producer/consumer broker namesrv 通信方式

producer/consumer 给 broker发送消息/消费消息,或者从 namesrv拉取消息 , 通信是​基于netty的方式,优先选用epoll方式,如果操作系统不支持epoll的话,会选择NIO。