ConsumeQueue

引言：索引的魔法 如果说 CommitLog 是一本厚厚的字典，那么 ConsumeQueue 和 IndexFile 就是目录和索引。它们让 RocketMQ 能够： 秒级定位：从百万条消息中快速找到目标 轻量高效：索引占用空间极小 多维查询：支持按 Queue、Key、时间查询 今天我们深入剖析这两种索引的巧妙设计。 一、为什么需要索引？ 1.1 没有索引的困境 场景：Consumer 想消费 TopicA 的消息 方案1：遍历 CommitLog（❌） ┌────────────────────────────────────┐ │ CommitLog（所有Topic混存） │ ├────────────────────────────────────┤ │ TopicA-Msg1 │ │ TopicB-Msg1 │ ← 需要跳过 │ TopicC-Msg1 │ ← 需要跳过 │ TopicA-Msg2 │ │ TopicB-Msg2 │ ← 需要跳过 │ ... │ └────────────────────────────────────┘ 问题： 1. 需要扫描所有消息 → 慢 2. 无法按 Queue 过滤 → 低效 3. 无法快速定位 Offset → 不可用 1.2 RocketMQ 的索引方案 ┌─────────────────────────────────────────────┐ │ 双层索引架构 │ ├─────────────────────────────────────────────┤ │ │ │ ConsumeQueue（消费索引） │ │ - 按 Topic-Queue 组织 │ │ - 存储消息在 CommitLog 的位置 │ │ - 支持顺序消费 │ │ │ │ IndexFile（查询索引） │ │ - 按 Key/时间 组织 │ │ - Hash 索引结构 │ │ - 支持随机查询 │ │ │ └─────────────────────────────────────────────┘ 二、ConsumeQueue：消费索引 2.1 文件组织结构 $HOME/store/consumequeue/ ├── TopicA/ # Topic 名称 │ ├── 0/ # Queue ID = 0 │ │ ├── 00000000000000000000 # 第1个文件 │ │ ├── 00000000000600000000 # 第2个文件 │ │ └── ... │ ├── 1/ # Queue ID = 1 │ │ └── ... │ └── ... ├── TopicB/ │ └── ... └── ... 文件大小：600万字节（30万条索引 × 20字节） 文件名：该文件第一条索引的逻辑偏移量 2.2 索引格式 ┌────────────────────────────────────┐ │ 单条索引格式（20字节） │ ├────────────────────────────────────┤ │ CommitLog Offset (8字节) │ ← 消息在 CommitLog 的物理位置 │ Size (4字节) │ ← 消息大小 │ Tag HashCode (8字节) │ ← Tag 哈希值（用于过滤） └────────────────────────────────────┘ 实际示例： ...

引言：存储引擎的设计哲学 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 根据索引快速定位 │ │ │ └─────────────────────────────────────────────────┘ 优势： ...