RockMQ消息的储存

1. 消息存储的整体结构

RocketMQ 采用文件系统的方式来存储消息，消息的主要存储文件包括 CommitLog 文件、ConsumeQueue 文件、IndexFile 文件.

CommitLog文件

• CommitLog 是消息存储的物理文件, 所有消息主题的消息都存储在 CommitLog 文件中;
• 每个 Broker 上的 CommitLog 被当前机器上的所有 ConsumeQueue 共享。
• CommitLog 中的文件默认大小为 1G，可以动态配置；当一个文件写满以后，会生成一个新的 CommitLog 文件。
• 所有的 Topic 数据是顺序写入在 CommitLog 文件中的。
• Commit log存储消息实体。顺序写，随机读。

[ 磁盘存储的“快”——顺序写 ]

磁盘存储，使用得当，磁盘的速度完全可以匹配上网络的数据传输速度，目前的高性能磁盘，顺序写速度可以达到600MB/s，超过了一般网卡的传输速度。

[ 磁盘存储的“慢”——随机写 ]

磁盘的随机写的速度只有100KB/s，和顺序写的性能差了好几个数量级。

[ 存储机制这样设计的好处——顺序写，随机读 ]

1.CommitLog顺序写，可以大大提高写入的效率；

2.虽然是随机读，但是利用package机制，可以批量地从磁盘读取，作为cache存到内存中，加速后续的读取速度。

3.为了保证完全的顺序写，需要ConsumeQueue这个中间结构，因为ConsumeQueue里只存储偏移量信息，所以尺寸是有限的。在实际情况中，大部分ConsumeQueue能够被全部读入内存，所以这个中间结构的操作速度很快，可以认为是内存读取的速度。

[ 如何保证CommitLog和ConsumeQueue的一致性？ ]

CommitLog里存储了Consume Queues、Message Queue、Tag等所有信息，即使ConsumeQueue丢失，也可以通过commitLog完全恢复出来。

ConsumeQueue

• ConsumeQueue 是消息消费的逻辑队列，消息达到 CommitLog 文件后将被异步转发到消息消费队列，供消息消费者消费, 这里面包含 MessageQueue 在 CommitLog 中的物理位置偏移量 Offset，消息实体内容的大小size和 Message Tag 的 hash 值。每个文件默认大小约为 600W 个字节，如果文件满了后会也会生成一个新的文件。

IndexFile

IndexFile 是消息索引文件，Index 索引文件提供了对 CommitLog 进行数据检索，提供了一种通过 key 或者时间区间来查找 CommitLog 中的消息的方法。在物理存储中，文件名是以创建的时间戳命名，固定的单个 IndexFile 大小大概为 400M，一个 IndexFile 可以保存 2000W 个索引。

附加介绍 PageCache与Mmap内存映射

page cache的概念: 系统的所有文件I/O请求，操作系统都是通过page cache机制实现的。对于操作系统来说，磁盘文件都是由一系列的数据块顺序组成，数据块的大小由操作系统本身而决定，x86的linux中一个标准页面大小是4KB。

操作系统内核在处理文件I/O请求时，首先到page cache中查找（page cache中的每一个数据块都设置了文件以及偏移量地址信息），如果未命中，则启动磁盘I/O，将磁盘文件中的数据块加载到page cache中的一个空闲块，然后再copy到用户缓冲区中。

page cache本身也会对数据文件进行预读取，对于每个文件的第一个读请求操作，系统在读入所请求页面的同时会读入紧随其后的少数几个页面。因此，想要提高page cache的命中率（尽量让访问的页在物理内存中），从硬件的角度来说肯定是物理内存越大越好。从操作系统层面来说，访问page cache时，即使只访问1k的消息，系统也会提前预读取更多的数据，在下次读取消息时, 就很可能可以命中内存。

在RocketMQ中，ConsumeQueue逻辑消费队列存储的数据较少，并且是顺序读取，在page cache机制的预读取作用下，Consume Queue的读性能会比较高近乎内存，即使在有消