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\topic_A\queue0-4\${fileName}
對於producer B來說，因為producer A和producer B不屬於同一group，相互不影響，topic_B也對應queue0-4，
consumequeue為${$storeRoot}\consumequeue\topic_B\queue0-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存的是索引
文件，這個文件用來加快消息查詢的速度。
