九、RocketMQ源码分析之消费队列、Index索引文件存储结构与存储机制-上篇

---

RocketMQ 存储基础回顾：源码分析RocketMQ之CommitLog消息存储机制

本文主要从源码的角度分析 Rocketmq 消费队列 ConsumeQueue 物理文件的构建与存储结构，同时分析 RocketMQ 索引文件IndexFile 文件的存储原理、存储格式以及检索方式。RocketMQ 的存储机制是所有的主题消息都存储在 CommitLog 文件中，也就是消息发送是完全的顺序 IO 操作，加上利用内存文件映射机制，极大的提供的 IO 性能。消息的全量信息存放在 commitlog 文件中，并且每条消息的长度是不一样的，消息的具体存储格式如下：

如果消费者直接基于commitlog 进行消费的话，简直就是一个恶梦，因为不同的主题的消息完全顺序的存储在 commitlog 文件中，根据主题去查询消息，不得不遍历整个 commitlog 文件，显然作为一款消息中间件这是绝不允许的。RocketMQ 的ConsumeQueue 文件就是来解决消息消费的。首先我们知道，一个主题，在 broker 上可以分成多个消费对列，默认为4个，也就是消费队列是基于主题+broker。那 ConsumeQueue 中当然不会再存储全量消息了，而是存储为定长（20字节，8字节commitlog 偏移量+4字节消息长度+8字节tag hashcode）,消息消费时，首先根据 commitlog offset 去 commitlog 文件组（commitlog每个文件1G，填满了，另外创建一个文件），找到消息的起始位置，然后根据消息长度，读取整条消息。但问题又来了，如果我们需要根据消息ID，来查找消息，consumequeue 中没有存储消息ID,如果不采取其他措施，又得遍历 commitlog文件了，为了解决这个问题，rocketmq 的 index 文件又派上了用场。

接下来，本文重点关注 ConsumeQueue、Index 文件是如何基于 Commitlog 构建的，并且根据 ConsumeQueue、Index 文件如何查找消息。