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

10年积累的成都做网站、网站建设、外贸营销网站建设经验，可以快速应对客户对网站的新想法和需求。提供各种问题对应的解决方案。让选择我们的客户得到更好、更有力的网络服务。我虽然不认识你，你也不认识我。但先网站制作后付款的网站建设流程，更有奈曼免费网站建设让你可以放心的选择与我们合作。

一、消息存储整体架构

一个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消息存储架构是怎么样的”这篇文章的所有内容，感谢各位的阅读！相信大家都有了一定的了解，希望分享的内容对大家有所帮助，如果还想学习更多知识，欢迎关注创新互联行业资讯频道！

网页标题：RocketMQ中broker消息存储架构是怎么样的
文章源于：http://azwzsj.com/article/jpsjeg.html