RocketMQ存储模型

简介

RocketMQ有Producer、Consumer、NameSrv、Broker四个部分。其中Broker用于存储消息，维护消息队列和订阅关系，是RocketMQ四个部分中最重要的一个部分，并且RocketMQ的高性能就是依赖于Broker模块的底层存储模型实现的。所以搞清楚Broker的存储模型是学习RocketMQ最重要的一步。

存储模型

下图就是RocketMQ消息和一些配置的磁盘文件目录：

下面就对这个目录详细介绍

CommitLog

CommitLog目录下的文件，为消息存储文件，所有的topic的消息都会存放在这个目录下的文件里，消息格式如下图，文件名称为消息的起始偏移量（可以简单理解为文件的第一个消息的偏移量），每个文件大小为1G（至于为什么是1G？和Mmap有关，Mmap在做文件映射的时候大小限制在1.5GB~2GB之间）。
由于消息写入会加锁，每个消息写入都是将消息追加到文件最后，所以消息是顺序写入的，并且充分利用OS的Mmap(减少拷贝次数)和PageCache(预读机制)技术，使CommitLog的读写性能很高，很接近内存读写。

写入消息源码入口：CommitLog#asyncPutMessage
读取消息源码入口：CommitLog#getData

ConsumerQueue

ConsumerQueue目录下是Broker存储的topic名称，每个topic就是一个目录，每个topic目录下又有几个Queue目录，Queue目录下是消息队列文件，如下图：

ConsumerQueue保存了每个topic的每个queue消息数据 在CommitLog中的位置，消费者消费时从ConsumeQueue中消费，然后根据偏移量快速定位到CommitLog中获取完整的消息，其实相当于数据库索引。它有三个字段：commitLogOffset、size、tag，其中的offset就是消息的偏移量，tag用于过滤消息。每个ConsumeQueue可以保存30W个消息信息。

如果是Consumer是集群消费模式，Consumer的消费偏移量offset是存储在Broker端的config/consumerOffset.json文件中，这个文件里保存了每个消费者组的消费消息的偏移量。

它的写入是Broker端的后台服务线程—ReputMessageService读取CommitLog文件。
写入索引源码入口：CommitLogDispatcherBuildConsumeQueue#dispatch

IndexFile

index目录是存储的消息Key的文件索引，作用是通过Key和时间范围来查询消息。存储的内容都是Topic+key值生成的哈希键，值为消息在CommitLog中的偏移量和时间戳等信息，并且使用链表思想解决Hash冲突。文件名称时间戳。

它的写入是Broker端的后台服务线程—ReputMessageService读取CommitLog文件。
写入源码入口：CommitLogDispatcherBuildIndex#dispatch

总结

Broker的高性能消息存储，主要是采用CommitLog、ConsumerQueue和IndexFile实现的，而且充分采用Mmap和PageCache技术。