rocketmq是我們常用的消息中間件之一，現在我們就來分析一下，它是如何存儲和讀取消息的。
rocketmq是把消息持久化在本地的文件系統的，所有的消息，都保存在commitLog文件中，這個文件是不區分topic或者messageQueue的，所有的消息，都是保存在一起，這個點跟常見的kafka不同，kafka不同的分區，是保存在不同的文件中的，但是也因此引發了別的問題，就是在分區特別多的時候，由於文件數量太多，導致數據的讀取效率急速下降，一般在幾十個分區左右，不建議使用過多的分區，但是rocketmq最多可以支持上萬的topic，就是因爲兩者的文件存儲不同。因爲rocketmq文件存儲使用的是同一個文件，所以消息的寫入是順序的，每來一個消息，寫入文件尾就可以了，效率很快。
但是光使用一個commitLog文件，肯定是不行的，因爲不同的消費者，消費的messageQueue不同（這個具體可以看rocketmq的消費模型），不能每次拉取消息時，服務端都要遍歷commitLog，然後找到對應的消息返回，這樣效率太低了，這個時候，rocketmq使用的就是ConsumeQueue文件，該文件可以理解爲是邏輯上的隊列，一個consumeQueue文件，對應一個服務端上的messageQueue，但是裏面存儲的不是真正的消息體，而是該MessageQueue裏面消息存儲在commitLog文件中的的位置，所以文件尺寸是很小的，實際情況下，大部分的consumeQueue都是能全部存入內存中的，也就是可以很快的知道該messageQueue中的下一條消息在commitLog的位置，再通過RandomAccessFile來實現隨機讀，同樣可以達到很快的消息讀取效率。
rocketmq的存儲結構如圖所示，producer發送消息到服務端之後，直接存儲在commit Log文件中，同時根據消息的messageQueue信息，在對應的comsumeQueue文件的尾部，添加這條消息的記錄，也就是在commitLog文件中的位置，不同的消費者，根據消費的MessageQueue，通過對應的ConsumeQueue獲取消息位置，並獲取消息。
總體來說，rocketmq是通過實現順序讀，隨機寫，來保證自己的效率的。
