CommitLog
生产者向Broker发送的消息，会以顺序写的方式，写入CommitLog文件，CommitLog文件的根目录由配置参数storePathRootDir决定，默认每一个CommitLog的文件大小为1G，如果文件写满会新建一个CommitLog文件，以该文件中第一条消息的偏移量为文件名，小于20位用0补齐：
比如第一个文件中第一条消息的偏移量为0，那么第一个文件的名称为00000000000000000000，当这个文件存满之后，需要重新建立一个CommitLog文件，一个文件大小为1G，
1GB = 102410241024 = 1073741824 Bytes，所以下一个文件就会被命名为00000000001073741824。
数据格式
CommitLog中存储的每条消息的数据格式如下：
- 消息总长度，占4个字节；
- 魔数，占4个字节；
- 消息体CRC校验和，占4个字节；
- 队列ID，占4个字节；
- 标识，占4个字节；
- 队列的偏移量，占8个字节；
- 消息在文件的物理偏移量，占8个字节；
- 系统标识，占4个字节；
- 发送消息的时间戳，占8个字节；
- 发送消息的主机地址，占8个字节；
- 存储时间戳，占8个字节；
- 存储消息的主机地址，占8个字节；
- 消息的重试次数，占4个字节；
- 事务相关偏移量，占8个字节；
- 消息内容的长度，占4个字节；
- 消息内容，由于消息内容不固定，所以长度不固定；
- 主题名称的长度，占1个字节；
- 主题名称内容，长度不固定；
- 消息属性长度，占2个字节；
- 消息属性内容，长度不固定；
RocketMQ一般会保存一个物理偏移量offSet，从CommitLog中获取消息内容。
ConsumeQueue
RocketMQ在消息存储的时候将消息顺序写入CommitLog文件，如果想根据Topic对消息进行查找，需要扫描所有CommitLog文件，这种方式性能低下，所以RocketMQ又设计了ConsumeQueue存储消息的逻辑偏移量，offset逻辑偏移量从0开始编号，进行递增，消息写入CommitLog以后，会构建对应的 ConsumeQueue文件。
在RocketMQ的存储文件目录下，有一个consumequeue文件夹，里面按Topic分组，每个Topic一个文件夹，Topic文件夹内是该Topic的所有消息队列，以消息队列ID命名文件夹，每个消息队列都有自己对应的ConsumeQueue文件：
ConsumeQueue中存储的每条数据大小是固定的，总共20个字节，数据格式如下：
- 消息在CommitLog文件的偏移量，占用8个字节；
- 消息大小，占用4个字节；
- 消息Tag的hashcode值，用于tag过滤，占用8个字节；
消费进度
消费者在拉取消息进行消费的时候，就是通过这个ConsumeQueue实现的，消费者在向Broker发送消息拉取请求之前，需要知道应该从哪条消息开始消费，对于广播模式，消息的消费进度保存在消费者端本地，对于集群模式，消息的消费进度保存在Broker中，所以拉取某个消息队列的消息之前，会向Broker发送请求，获取该消息队列的消费进度，消费进度在RocketMQ的存储目录中有一个对应的文件，叫consumerOffset.json，里面的offsetTable中保存了每个消息队列的消费进度，这个消费进度值对应的就是ConsumeQueue中的逻辑偏移量，它由定时任务定时进行持久化：
{
"offsetTable":{
"TestTopic@TestTopicGroup":{ // 主题名称@消费者组名称
0:0, // 每个消息队列对应的消费进度，Key中的0表示队列0，value中的0表示消息在ConsumeQueue中的逻辑偏移量
1:1,
2:1,
3:0
}
}
}
拿到消息队列对应的消费进度时，就可以根据这个值从Broker拉取消息，Broker收到请求后，会根据这个值从ConsumeQueue中获取此条消息在CommitLog中的物理偏移量，根据物理偏移量再从CommitLog中获取消息内容返回给消费者。
总结
当消息写入CommitLog之后会构建对应的ConsumeQueue文件，每个消息队列MessageQueue都会有一个对应的ConsumeQueue文件，ConsumeQueue文件中的offset记录的是消息的逻辑索引，从0开始编号进行递增，比如存入了3条消息，那么对应的offset分别为0、1、2，消费者在消费的时候拿到的消费进度就是这个offset，然后根据offset从ConsumeQueue文件中获取数据，里面记录了消息在CommitLog文件中的物理偏移量，之后就可以从CommitLog中获取消息内容。
消费者消费完毕之后，会保存这个消费进度，对于集群模式，消费进度会保存在Borker端，Broker会定时将消费进度进行持久化，如果消费者刚启动的时候，会向Broker发起请求获取之前记录的消费进度。
IndexFile
为了便于消息查找，RocketMQ还设计了IndexFile，支持根据Key对消息进行查找，在发送消息的时候可以设置一个唯一Keys值，用于标识这条消息，之后就可以根据这个Keys值对消息进行查找。
Message msg = new Message(topic, RandomUtils.getStringByUUID().getBytes());
// 订单Id
String orderId = "20034568923546";
msg.setKeys(orderId);
IndexFile文件结构
每个indexFile文件的大小是固定的，一个IndexFile文件大约可以保存2000W个消息的索引，IndexFile的文件结构如下：
IndexHeader
index header记录indexFile文件的整体信息，占40个字节，有以下信息：
- beginTimestamp：当前indexFile文件中第一条消息的存储时间；
- endTimestamp：当前indexFile文件中最后一条消息存储时间；
- beginPhyoffset：当前indexFile文件中第一条消息在Commitlog中的偏移量；
- endPhyoffset：当前indexFile文件中最后一条消息在commitlog中的偏移量；
- hashSlotCount：已经使用的hash槽的个数；
- indexCount：索引项中记录的所有消息索引总数；
hash slot
RocketMQ在每个IndexFile文件中划分了500W个hash槽，在向文件中添加消息索引的时候，会取出消息的Keys（实际会使用Topic + "#" + key进行拼装做为IndexFile文件的Key）计算hash值，然后对hash槽总数取余，来判断应该放到哪个hash槽。
index item
索引项中记录每个Key的索引信息，有以下部分组成：
- keyHash：消息的key计算出来的的hashcode值，
- phyOffset：消息在CommitLog中的物理偏移量；
- timeDiff：消息的存储时间减去IndexHeader中的beginTimestamp（当前indexFile文件中第一条消息的存储时间）；
- preIndexNo：当哈希冲突的时候，用于指向上一个索引，可以看做当哈希冲突的时候，使用一个链表将该哈希槽下的所有元素串起来，使用头插法增加新的元素；
消息索引添加
举个例子，比如现在有一条消息，它的Key值1，假设哈希槽的个数为10，这里对哈希计算简化，直接用1对哈希槽个数取余，得到值为0，那么这条消息将落入哈希槽0的位置，然后会在索引项区域建立该消息的索引信息：
如果新增一条消息2，它的Key值为2，用2对哈希槽个数取余，依旧得到哈希槽0，此时产生哈希冲突，将哈希槽0处存储的值改为消息2的索引项，并将消息2索引项中的preIndexNo指向消息1的索引项，形成一个链表：