来源：RocketMQ的存储模型和底层优化策略有哪些

RocketMQ 存储模型与底层优化深度解析

RocketMQ 的存储设计遵循一个核心理念：极致的顺序写，配合灵活的随机读。

第一层：宏观存储架构（The Big Picture）

RocketMQ 的存储文件主要由三个核心部分组成：CommitLog、ConsumeQueue 和 IndexFile。我们可以用“图书馆”来类比这个模型。

1. 三大核心文件

文件类型
作用
对应图书馆类比
关键特性

CommitLog
消息主体存储。无论哪个Topic的消息，全部混在一起顺序写入这个大文件。
书库的所有书籍（按入库时间堆放，不分类）
顺序写，单个默认1GB，文件名是起始偏移量。

ConsumeQueue
逻辑消费队列。主要存储消息在CommitLog中的偏移量，供消费者拉取。
索引卡片/分类目录（按类别分类，指向书的位置）
索引文件，定长设计（20字节），轻量级。

IndexFile
哈希索引。提供根据 Key 或时间区间查询消息的能力。
书名/作者检索电脑
底层是Hash表结构，用于运维排查。

2. 存储结构图解

[嵌入内容: diagram]

---

第二层：核心优化策略（The Secret Sauce）

RocketMQ 为什么快？核心在于它绕过了操作系统标准IO的瓶颈。

1. 顺序写（Sequential Write）

磁盘（尤其是机械硬盘HDD）最怕随机IO（磁头频繁寻道）。

• RocketMQ的做法：所有 Topic 的消息全部写入同一个 CommitLog。
• 效果：将随机写变成了顺序写。实验表明，磁盘顺序写的速度（约600MB/s）可以媲美内存的随机写。

2. 零拷贝技术（Zero Copy）与 mmap

这是 Java 高性能 IO 的基石。

传统 IO 的痛点

普通的 read/write 操作需要4次拷贝和4次上下文切换：
Disk -> Kernel Buffer -> User Buffer -> Kernel Socket Buffer -> NIC (网卡)。

mmap (内存映射文件)

RocketMQ 使用 Java NIO 的 MappedByteBuffer。

• 原理：将内核空间的 PageCache 直接映射到用户空间的虚拟地址。

• 效果：

• 写数据：直接写入用户态的内存地址（实际是 PageCache），由 OS 异步刷盘。

• 读数据：直接从 PageCache 读取，少了一次内核到用户的拷贝。

• 限制：MappedByteBuffer 单个文件限制在 1.5GB - 2GB 左右，所以 RocketMQ 的 CommitLog 设定为 1GB。

Java 代码演示 mmap

import java.io.RandomAccessFile;
import java.nio.MappedByteBuffer;
import java.nio.channels.FileChannel;

public class MmapDemo {
    public static void main(String[] args) throws Exception {
        // 模拟 RocketMQ 创建 CommitLog
        RandomAccessFile raf = new RandomAccessFile("00000000000000000000", "rw");
        FileChannel channel = raf.getChannel();
        
        // 核心代码：内存映射
        // MapMode.READ_WRITE: 读写模式
        // 0: 起始位置
        // 1024 * 1024 * 1024: 映射大小 (1GB)
        MappedByteBuffer mappedByteBuffer = channel.map(FileChannel.MapMode.READ_WRITE, 0, 1024 * 1024 * 1024);
        
        // 写数据 (看起来像写内存一样，其实直接进了 PageCache)
        String msg = "Hello RocketMQ Storage!";
        mappedByteBuffer.put(msg.getBytes());
        
        // 强制刷盘 (可选，RocketMQ有专门的刷盘线程)
        // mappedByteBuffer.force(); 
        
        System.out.println("Write success without User-Kernel copy!");
        
        // 资源清理...
    }
}

3. PageCache 与 预读（Readahead）

RocketMQ 严重依赖操作系统的 PageCache（页缓存）。

• 写：消息先写入 PageCache，立刻返回 ACK，不仅快，而且利用了 OS 的掉电保护（尽力而为）。

• 读：

• 消费者拉取最新消息时，数据就在 PageCache 中，命中率极高，几乎无需读盘。

• 产生堆积读取历史消息时，OS 的预读机制（Read-ahead）会将相邻的数据块预先加载到 PageCache，因为 CommitLog 是顺序存储的，预读效果极佳。

---

第三层：进阶优化——读写分离（TransientStorePool）

这是 RocketMQ 的大杀器。

在开启 transientStorePoolEnable=true 后（通常在 Master 节点开启），RocketMQ 会引入堆外内存池。

为什么需要这个？

如果使用默认的 MappedByteBuffer，高并发下，写入（生产）和读取（消费）都在竞争 PageCache。如果消费者消费滞后，会从磁盘读取冷数据到 PageCache，把热数据的 PageCache 挤出去，导致生产者写入性能抖动。

优化后的流程

1. Write：消息先写入 DirectByteBuffer (堆外内存池，Java完全控制)。
2. Commit：后台线程异步将 DirectByteBuffer 的数据写入 FileChannel (进入 PageCache)。
3. Flush：后台线程将 PageCache 刷入 Disk。

好处：实现了数据写入与 PageCache 的解耦。生产者直接写内存，极其稳定；消费者读 PageCache，互不干扰。

---

第四层：ConsumeQueue 的极致压缩

ConsumeQueue 是消费者能快速定位消息的关键。它采用定长设计，每条记录固定 20 Bytes。

数据结构

┌───────────────────────────────┐
│ CommitLog Offset (8 Bytes)    │ -> 消息在 CommitLog 中的物理地址
├───────────────────────────────┤
│ Message Size     (4 Bytes)    │ -> 消息长度
├───────────────────────────────┤
│ Tags HashCode    (8 Bytes)    │ -> Tag的哈希值（用于服务端过滤）
└───────────────────────────────┘

为什么这样设计？

1. 随机读变顺序读：因为是定长，要找第 N 条消息，直接计算位置：Pos = N * 20。
2. 服务端过滤：Consumer 拉取消息时，Broker 可以直接根据 Tags HashCode 过滤，不需要读取 CommitLog 中的具体内容，极大节省 IO。
3. 内存驻留：30W 条消息的索引仅 5.7MB，极易被 PageCache 完全缓存。

---

总结：RocketMQ 存储性能公式

通过这种将硬盘当内存用的设计，RocketMQ 实现了在普通硬件上单机十万级甚至百万级的 TPS。