图解RocketMQ架构

AlbenXie

于 2024-09-18 00:29:22 发布

阅读量19

点赞数

文章标签： rocketmq 架构

原文链接：https://mp.weixin.qq.com/s/muZd3xsKnFkfnEjBfOW2mA

版权

写在前面

Kafka、RocketMQ都是很出名的中间件，上次我们讲解了Kafka，这次我们来讲讲RocketMQ的原理。

基本架构图

简易架构

解析

RocketMQ 总共可以分成四个模块

NameServer：提供服务发现和路由功能，管理各种元数据信息。
Broker：消息存储和路由分发节点，负责存储消息和将消息路由给消费者。
Producer：消息生产者，负责产生并发送消息到指定的 Topic。
Consumer：消息消费者，订阅 Topic 并从 Broker 拉取消息进行处理。

大体读写步骤

注册 Broker Cluster 到 NameServer。
注册 Producer、Consumer 到 NameServer。
Producer 获取MQ集群的Broker、Queue等信息。
Producer 发消息，一般消息都会选择master进行写入，而slave进行读取。
顺序写入消息到 commit log 中。
queue log会记录每条commit log的存储信息，当然不会记录所有，只记录一些重要的，commitLogOffset等等。
master 将消息异步给slave。
Consumer读取slave的消息。
Consumer返回ACK作为确认消息消费成功。

1. NameServer

当Broker服务启动后，会向NameServer注册信息，比如broker中的Topic、消费偏移量、队列、ip、端口等，由Broker的心跳发送到NameServer，BrokerCluster 中的每一个节点都会注册到NameServer上。

即使一个NameService节点挂了，剩下的一个NameService节点仍然包含所有的broker信息。不过NameService是无状态的， NameService之间不会相互通信，那么一个NameService挂了，不会影响另外一个NameService。

注册完Broker之后，NameServer会每隔10s发送心跳检查Broker，如果Broker超过120s还没有响应，则这个Broker被视为宕机

2. Broker

2.1 CommitLog & Message Queue

Broker 启动，跟所有的 NameServer 保持长连接，每 30s 发送一次发送心跳包（像心跳一样持续稳定的发送请求）。心跳包中包含当前 Broker 信息 ( IP+ 端口等）以及存储所有 Topic 信息。注册成功后，NameServer 集群中就有 Topic 跟 Broker 的映射关系。

Broker接受消息，会顺序写入消息到 CommitLog 中。Broker里面的两个存储介质：Commit log 和 Message queue的区别：

Commit log 存储消息实体。顺序写，随机读。虽然是随机读，但是利用package机制，可以批量地从磁盘读取，作为cache存到内存中，加速后续的读取速度。
Message queue 存储消息的偏移量。读消息先读 message queue，根据偏移量到 commit log 读消息本身。

所以其实我们的消息不是存放在queue中，而是存放在commit log中，这就是为什么queue会被称为逻辑队列

2.2 Index File

2.2.1 介绍

因为所有的消息都存在CommitLog中，如果要实现根据 key 查询消息的方法，就会变得非常困难，所以为了解决这种业务需求，有了IndexFile的存在。用于为生成的索引文件提供访问服务，通过消息 Key 值查询消息真正的实体内容。

IndexFile 如何创建？以创建的时间戳命名。参数：phyOffset物理偏移量（也就是commitLogOffset）、keys。

如何查询消息呢？

2.2.2 按照MessageId查询

RocketMQ中的MessageId的长度总共有16字节，其中包含了消息存储主机地址（IP地址和端口），消息Commit Log offset。

Client 端从 MessageId 中解析出 Broker 的地址（IP地址和端口）和Commit Log的偏移地址发送一个RPC请求。
Broker 端读取消息的过程用其中的 commitLog offset 和 size 去 commitLog 中找到真正的记录并解析成一个完整的消息返回。

通过id查询

2.2.3 按照Message Key查询

找槽位：slotKey = 40 byte + hash(topic + "#" + key) % 500W * 4byte。
计算槽位：slotValue = 最新插入 index 的位置。
遍历单向链表：从 slotValue 找到最新 index 在整个索引文件中位置 = 40byte +500w*4byte + slotValue*20byte，然后根据单个索引文件的 pre index 值找到前一个索引，一直遍历下去，直到index数据中key hash和时间区间都满足即可。添加到 commitLogOffset 的 list) 中。
最终根据其中的 commitLogOffset 从 CommitLog 文件中读取消息的实体内容。