CommitLog

引言：顺序写的魔力 CommitLog 是 RocketMQ 高性能的核心秘密。它用顺序写实现了： 单机 10 万+ TPS：远超数据库的随机写 亚毫秒级延迟：消息写入延迟 < 1ms 零拷贝读取：MMAP 直接访问磁盘文件 今天我们从源码级别剖析 CommitLog 的实现细节。 一、为什么顺序写这么快？ 1.1 随机写 vs 顺序写 ┌──────────────────────────────────────────┐ │ 磁盘写入性能对比 │ ├──────────────────────────────────────────┤ │ │ │ 随机写（数据库）: │ │ ┌───┐ ┌───┐ ┌───┐ │ │ │ A │ → │ C │ → │ B │ │ │ └───┘ └───┘ └───┘ │ │ 磁盘块100 磁盘块500 磁盘块200 │ │ │ │ 问题： │ │ - 磁头需要频繁移动 │ │ - IOPS 约 100-200/s │ │ │ ├──────────────────────────────────────────┤ │ │ │ 顺序写（RocketMQ）: │ │ ┌───┬───┬───┬───┬───┐ │ │ │ A │ B │ C │ D │ E │ ... │ │ └───┴───┴───┴───┴───┘ │ │ CommitLog 文件 │ │ │ │ 优势： │ │ - 磁头连续移动 │ │ - 吞吐量 约 600MB/s（机械硬盘） │ │ - 吞吐量 约 2GB/s（SSD） │ │ │ └──────────────────────────────────────────┘ 性能差距： ...

引言：存储引擎的设计哲学 RocketMQ 的存储引擎是其高性能的核心。它用极简的设计实现了： 百万级 TPS：单机支持百万级消息吞吐 毫秒级延迟：消息存储延迟 < 1ms TB 级存储：单 Broker 可存储数 TB 消息 零数据丢失：通过刷盘策略保证可靠性 今天我们从第一性原理出发，逐步理解这个存储引擎的巧妙设计。 一、为什么需要这样的存储模型？ 1.1 传统数据库存储的问题 方案1：为每个 Queue 建一张表 -- TopicA 的 Queue0 CREATE TABLE topic_a_queue_0 ( offset BIGINT PRIMARY KEY, message BLOB, store_time TIMESTAMP ); -- TopicA 的 Queue1 CREATE TABLE topic_a_queue_1 (...); ... 问题： 1. 表数量爆炸：1000个Topic × 4个Queue = 4000张表 2. 随机写入：不同表的写入是随机I/O → 性能差 3. 数据分散：难以统一管理和备份 1.2 RocketMQ 的解决方案 核心思想：写入集中化 + 读取索引化 ┌─────────────────────────────────────────────────┐ │ RocketMQ 存储模型 │ ├─────────────────────────────────────────────────┤ │ │ │ 所有消息 → 统一写入 CommitLog（顺序写） │ │ ↓ │ │ 异步构建 ConsumeQueue（索引） │ │ ↓ │ │ Consumer 根据索引快速定位 │ │ │ └─────────────────────────────────────────────────┘ 优势： ...