RocketMQ 存储机制浅析
内容提要
RocketMQ是发布订阅体系，通过Broker节点解耦上下游。存储模型采用音讯刷盘至文件系统做持久化。RocketMQ使用PageCache机制和异步刷盘提升性能。
延伸解读
存储模型的核心优势
RocketMQ 的存储模型通过 CommitLog 和 ConsumeQueue 的分离设计，实现了高效的消息存储与检索。CommitLog 顺序写入所有消息，保证了高吞吐；ConsumeQueue 则记录消息在 CommitLog 中的偏移量，帮助消费者快速定位。这种设计既利用了磁盘顺序写入的性能，又通过索引机制支持随机读取，是 RocketMQ 高性能的关键。
异步刷盘的风险与权衡
RocketMQ 默认采用异步刷盘，消息先写入 PageCache 即返回成功，由操作系统异步刷盘。这提升了吞吐量，但若 Broker 在刷盘前宕机，消息会丢失。此外，脏页回写、内存回收等可能引起读写延迟。因此，在对可靠性要求极高的场景，需考虑同步刷盘或结合其他机制来平衡性能与数据安全。
零拷贝技术的选择
RocketMQ 使用 mmap 实现零拷贝，而非 sendfile。原因在于消息存储既有写也有读，sendfile 适用于发送文件到网络，但用户态不可见，无法满足读写需求。mmap 将文件映射到虚拟内存，用户态可直接操作，且不受 JVM 堆内存限制。但映射大小受操作系统虚拟内存约束，通常一次映射 1.5~2G，因此 CommitLog 文件默认设为 1G。
文件结构与数据恢复
Broker 的存储目录包含 abort、checkpoint、commitlog、consumequeue、index 等文件。abort 文件用于判断上次是否正常关闭；checkpoint 记录各文件的刷盘时间点，用于异常恢复。若 Broker 异常退出，重启时会根据 checkpoint 恢复数据。这种设计确保了数据的完整性和可恢复性，是 RocketMQ 可靠性的重要保障。
Q&A
RocketMQ的存储机制是如何工作的？
RocketMQ通过将音讯刷盘至文件系统实现持久化，使用Broker节点解耦上下游，并采用PageCache机制和异步刷盘提升性能。
RocketMQ的CommitLog文件有什么特点？
CommitLog文件是所有Topic的有序存储，默认大小为1G，文件名为起始偏移量，支持快速定位音讯。
ConsumeQueue在RocketMQ中有什么作用？
ConsumeQueue记录音讯在CommitLog中的偏移量，帮助消费者快速定位音讯，提升消费效率。
RocketMQ如何提升读写性能？
RocketMQ通过顺序写入、PageCache机制和零拷贝技术（mmap和sendfile）来提升读写性能。
RocketMQ的异步刷盘有什么风险？
异步刷盘可能导致数据丢失风险，因为在Broker宕机时，音讯可能尚未写入底层磁盘文件。
RocketMQ的IndexFile结构是怎样的？
IndexFile结构支持通过MsgID或MessageKey查询音讯，提升读取速度，便于快速定位音讯。
