RocketMQ中broker消息存储架构是怎么样的

这篇文章主要为大家展示了“RocketMQ中broker消息存储架构是怎么样的”，内容简而易懂，条理清晰，希望能够帮助大家解决疑惑，下面让小编带领大家一起研究并学习一下“RocketMQ中broker消息存储架构是怎么样的”这篇文章吧。

一、消息存储整体架构

一个broker下所有topic的消息都顺序存储在同一个数据日志文件（commit log file）中。同时broker还维护了一个索引文件（index file）记录了msg key的反向索引关系，用于从key查找所有关联的msgs。对于消费端，broker会为每个topic下的子队列创建一个逻辑消费队列（ConsumeQueue），ConsumeQueue中存储的元素具有固定的20字节的长度，是一个指向commitlog中消息实体的指针。每个consumer的消费进度offset本质上就是ConsumeQueue中元素的index，能够通过commitlog offset获得具体的消息体。

broker在接收到producer发送的消息时，首先会把消息添加到commitlog文件的末尾，通过同步或者异步的方式刷盘。后续会有一个ReputMessageService的线程异步构建ConsumeQueue以及IndexFile。核心的存储文件如下图：

二、存储模型层次结构

broker的消息存储架构按依赖关系可以划分为以下层次：

其中，MappedFileQueue/MappedFile封装了底层的文件读写接口。RocketMQ使用JDK NIO中的MappedByteBuffer/FileChannel来使用操作系统的文件映射服务，将一个大文件直接映射到一个内存地址空间中。通过内存的读写实现了文件的读写操作，避免了数据从内核态向用户态的拷贝。MappedFile代表的就是一个被切分成固定大小的日志文件（commitlog默认切分大小为1G，文件名为该分片首字节在整个commitlog中的偏移）。多个MappedFile组成一个MappedFileQueue，形成一个完整的日志文件的视图。

三、核心实现类

消息存储核心实现类如下图：

DefaultMessageStore是整个存储子系统的入口，提供了消息写入/读取/查询的方法，并通过后台线程异步构建ConsumeQueue和IndexFile两个关键数据结构。

以上是“RocketMQ中broker消息存储架构是怎么样的”这篇文章的所有内容，感谢各位的阅读！相信大家都有了一定的了解，希望分享的内容对大家有所帮助，如果还想学习更多知识，欢迎关注亿速云行业资讯频道！