rocketmq 消息存储

　　RocketMQ的具体消息存储结构是怎样的呢？如何尽量保证顺序写的呢？先来看看整体的架构图，

　　RocketMQ消息的存储是由ConsumeQueue和CommitLog配合完成的，消息真正的物理存储文件是

CommitLlog，ConsumeQueue是消息的逻辑队列，类似数据库的索引文件，存储的是指向物理存储的地址。

每个Topic下的每个Message Queue都有一个对应的ConsumeQueue文件。文件地址在${$storeRoot}consu

-mequeue${topicName}${queueId}${fileName}。

　　例如：有一个broker_a，有4个写队列queue0-4，4个读队列queue0-4，这是有两个producer，producer A

发送topic_A 消息，producer B 发送topic_B消息；producer A和producer B属于不同的

consumerGroup（相同会异常 https://www.cnblogs.com/toUpdating/p/10009218.html），这时对于producer A来说

发现有queue0-4都可以发送消息，topic_A对应queue0-4，consumequeue为${$storeRoot}consumequeue opic_Aqueue0-4${fileName}

对于producer B来说，因为producer A和producer B不属于同一group，相互不影响，topic_B也对应queue0-4，

consumequeue为${$storeRoot}consumequeue opic_Bqueue0-4${fileName}，

　　以队列queue0的角度来看，即收到topic_A的消息，有接受到topic_B的消息，最终按照收到的顺序保存到commitLog中，consumequeue中则保存着相应的索引。

　　CommitLog以物理文件的方式存放，每台Broker上的CommitLog被本机器所有ConsumeQueue共享，

文件，文件地址：${user.home}store${commitlog}${fileName}。在CommitLog中，一个消息的存储长度

是不固定的，RocketMQ采取一些机制，尽量向CommitLog中顺序写，但是随机读。ConsumeQueue的内容

也会被写到磁盘里作持久存储。

　　存储机制这样设计有以下几个好处：

　　1）CommitLog顺序写，可以大大提高写入效率。

　　2）虽然是随机读，但是利用操作系统的pagecache机制，可以批量地从磁盘读取，作为cache存到

内存中，加速后续的读取速度。

　　3）为了保证完全的顺序写，需要ConsumeQueue这个中间结构，因为ConsumeQueue里只存偏移量

信息，所以尺寸是有限的，在实际情况中，大部分的ConsumeQueue能够被全部读入内存，所以这个中间

结构的操作速度很快，可以认为是内存读取的速度。此外为了保证CommitLog和ConsumeQueue的一致性，

CommitLog里存储了Consume Queues、Message Key、Tag等所有信息，即使ConsumeQueue丢失，也可

以通过commitLog完全恢复出来。

　　如下图所示是一个Broker在文件系统中存储的各个文件。我们可以看到commitlog文件夹、consume

-queue文件夹、还有在config文件夹中Topic、Consumer的相关信息。最下面那个文件夹index存的是索引

文件，这个文件用来加快消息查询的速度。