32张图带你解决RocketMQ所有场景问题

一、RocketMQ的基本原理

「RocketMQ基本架构图如下」

image.png

从这个架构图上我们可以知道，RocketMQ有4块核心部分：

• NameServer：管理Broker的信息，让使用MQ的系统感知到集群里面的broker

• Broker：主从架构实现数据多副本存储和高可用

• producer：生产者

• consumer：消费者

二、NameServer

2.1 Broker信息注册到哪个NameServer？

每台broker机器需要向所有的NameServer机器上注册自己的信息，防止单台NameServer挂掉导致Broker信息不全，保证NameServer的集群高可用。

2.2 Broker信息怎么注册？

基于Netty的网络通信。

2.3 Broker挂了如何感知？

• 「NameServer感知：30s心跳机制和120s故障感知机制」

image.png

broker会每隔30秒向NameServer发送一个的心跳 ，NameServer收到一个心跳会更新对应broker的最近一次心跳事件，然后NamServer会每隔十秒运行一个任务，去检查一下各个broker的最近一次心跳的时间，如果超过120s没有收到相应broker的心跳，则判定对应的broker已经挂掉。

三、Broker

3.1 Master-Slave模式

为了保证MQ的数据不丢失而且具备一定的高可用性，我们采用的是主从复制模式。

「RocketMQ自身的Master-Slave模式主采取的是Slave主动从Master拉取消息。」

3.2 究竟是如何从Master-Slave中进行读写呢？

image.png

• 生产者在写入消息时，一般写入到Master

• 消费者在拉取消息时，可能从Master拉取，也可能从Slave拉取，「根据Master的负载情况和Slave的同步情况，」 由Master给出建议

  • Master负载过高，建议下次从Slave获取消息

  • Slave未同步完全，建议下次从Master获取消息

3.3 Broker宕机分析

3.3.1 Slave宕机

对系统会存在一点影响，但是影响不大，只不过少了Slave Broker，「会导致所有的读写压力都集中在Master Broker上」

3.3.2 Master宕机：基于Dledger实现RocketMQ高可用自动切换

选举方式这里不做重点介绍。

image.png

四、生产者

4.1 MessageQueue是什么？

我们先看看Topic、Broker、Message之间的关系。

如图比如说一个TopicA有n条消息，然后一个TopicA中的n条数据分配放入给4个MessageQueue1-4。

image.png

「所以本质上来说就是一个数据分片机制，通过MessageQueue将一个Topic的数据拆分为很多数据分片，在每个Broker机器上都存储一些MessageQueue。通过这个方法可以实现分布式存储。」

4.2 生产者发送消息写入哪个MessageQueue？

image.png

因为从前面我们知道，生产者会跟NameServer通信获取相应Topic的路由数据，从而知道，「一个Topic有几个MessageQueue，哪些MessageQueue在哪台Broker机器上，通过对应的规则写入对应的MessageQueue。」

4.2.1 Master Broker故障分析

当MasterBroker宕机，此时SlaveBroker正在切换过程中，有一组Broker就没有Master可以写入。

此时我们可以打开Producer的「自动容错机制开关：sendLatencyFaultEnable」，比如说访问其中一个Broker发现网络延迟有1000ms还无法访问，我们会自动回避这个Broker一段时间，比如接下来3000ms内，就不会访问这个Broker。

过一段时间之后，MasterBroker修复好了，或者说SlaveBroker选举成功了，就可以提供给别人访问了。

image.png

4.3 Broker数据存储（核心环节）

「Broker数据存储实际上是MQ最核心的环节：」

• 消息吞吐量

• 消息不丢失

4.3.1 磁盘日志文件CommitLog

image.png

首先，Producer发送消息给Broker，「Broker接收到消息后，把这个消息直接顺序写入写入到磁盘上的一个日志文件，叫做CommitLog。」

• CommitLog是由很多磁盘文件组成

• 每个文件限定最多1GB

4.3.2 ConsumeQueue存储对应消息的偏移量

「在Broker中，每一个Topic下的每一个MessageQueue都会有对应一系列的ConsumeQueue文件。」

「Broker磁盘存储类似于文件树的形式存在：」

image.png

「ConsumeQueue中存储着对应MessageQueue中的消息在CommitLog中的物理偏移量地址offset。」

image.png

「如图：」

1. Broker接受消息，顺序写入消息到CommitLog中

2. 同时找到对应的TopicA/MessageQueue1/Cons