RocketMQ 優異的性能表現，必然繞不開其優秀的存儲模型 。 這篇文章，筆者按照自己的理解 , 嘗試分析 RocketMQ 的存儲模型，希望對大家有所啟發。 1 整體概覽 首先溫習下 RocketMQ 架構。 整體架構中包含四種角色 : Producer ：消息發佈的角色，Producer 通過 ...
RocketMQ 優異的性能表現，必然繞不開其優秀的存儲模型 。
這篇文章，筆者按照自己的理解 , 嘗試分析 RocketMQ 的存儲模型，希望對大家有所啟發。
1 整體概覽
首先溫習下 RocketMQ 架構。
整體架構中包含四種角色 :
-
Producer ：消息發佈的角色，Producer 通過 MQ 的負載均衡模塊選擇相應的 Broker 集群隊列進行消息投遞，投遞的過程支持快速失敗並且低延遲。
-
Consumer ：消息消費的角色，支持以 push 推，pull 拉兩種模式對消息進行消費。
-
NameServer ：名字服務是一個非常簡單的 Topic 路由註冊中心，其角色類似 Dubbo 中的 zookeeper ，支持 Broker 的動態註冊與發現。
-
BrokerServer ：Broker 主要負責消息的存儲、投遞和查詢以及服務高可用保證 。
本文的重點在於分析 BrokerServer 的消息存儲模型。我們先進入 broker 的文件存儲目錄 。
消息存儲和下麵三個文件關係非常緊密：
-
數據文件 commitlog
消息主體以及元數據的存儲主體 ；
-
消費文件 consumequeue
消息消費隊列，引入的目的主要是提高消息消費的性能 ；
-
索引文件 index
索引文件，提供了一種可以通過 key 或時間區間來查詢消息。
RocketMQ 採用的是混合型的存儲結構，Broker 單個實例下所有的隊列共用一個數據文件（commitlog）來存儲。
生產者發送消息至 Broker 端，然後 Broker 端使用同步或者非同步的方式對消息刷盤持久化，保存至 commitlog 文件中。只要消息被刷盤持久化至磁碟文件 commitlog 中，那麼生產者發送的消息就不會丟失。
Broker 端的後臺服務線程會不停地分發請求並非同步構建 consumequeue（消費文件）和 indexFile（索引文件）。
2 數據文件
RocketMQ 的消息數據都會寫入到數據文件中， 我們稱之為 commitlog 。
所有的消息都會順序寫入數據文件，當文件寫滿了，會寫入下一個文件。
如上圖所示，單個文件大小預設 1G , 文件名長度為 20 位，左邊補零，剩餘為起始偏移量，比如 00000000000000000000 代表了第一個文件，起始偏移量為 0 ，文件大小為1 G = 1073741824。
當第一個文件寫滿了，第二個文件為 00000000001073741824，起始偏移量為 1073741824，以此類推。
從上圖中，我們可以看到消息是一條一條寫入到文件，每條消息的格式是固定的。
這樣設計有三點優勢：
-
順序寫
磁碟的存取速度相對記憶體來講並不快，一次磁碟 IO 的耗時主要取決於：尋道時間和碟片旋轉時間，提高磁碟 IO 性能最有效的方法就是：減少隨機 IO，增加順序 IO 。
《 The Pathologies of Big Data 》這篇文章指出：記憶體隨機讀寫的速度遠遠低於磁碟順序讀寫的速度。磁碟順序寫入速度可以達到幾百兆/s，而隨機寫入速度只有幾百 KB /s，相差上千倍。
-
快速定位
因為消息是一條一條寫入到 commitlog 文件 ，寫入完成後，我們可以得到這條消息的物理偏移量。
每條消息的物理偏移量是唯一的， commitlog 文件名是遞增的，可以根據消息的物理偏移量通過二分查找，定位消息位於那個文件中，並獲取到消息實體數據。
-
通過消息 offsetMsgId 查詢消息數據
消息 offsetMsgId 是由 Broker 服務端在寫入消息時生成的 ，該消息包含兩個部分：
-
Broker 服務端 ip + port 8個位元組；
-
commitlog 物理偏移量 8個位元組 。
我們可以通過消息 offsetMsgId ，定位到 Broker 的 ip 地址 + 埠 ，傳遞物理偏移量參數 ，即可定位該消息實體數據。
-
3 消費文件
在介紹 consumequeue 文件之前， 我們先溫習下消息隊列的傳輸模型-發佈訂閱模型 ， 這也是 RocketMQ 當前的傳輸模型。
發佈訂閱模型具有如下特點：
- 消費獨立：相比隊列模型的匿名消費方式，發佈訂閱模型中消費方都會具備的身份，一般叫做訂閱組（訂閱關係），不同訂閱組之間相互獨立不會相互影響。
- 一對多通信：基於獨立身份的設計，同一個主題內的消息可以被多個訂閱組處理，每個訂閱組都可以拿到全量消息。因此發佈訂閱模型可以實現一對多通信。
因此，rocketmq 的文件設計必須滿足發佈訂閱模型的需求。
那麼僅僅 commitlog 文件是否可以滿足需求嗎 ？
假如有一個 consumerGroup 消費者，訂閱主題 my-mac-topic ，因為 commitlog 包含所有的消息數據，查詢該主題下的消息數據，需要遍曆數據文件 commitlog , 這樣的效率是極其低下的。
進入 rocketmq 存儲目錄，顯示見下圖：
- 消費文件按照主題存儲，每個主題下有不同的隊列，圖中 my-mac-topic 有 16 個隊列 ;
- 每個隊列目錄下 ，存儲 consumequeue 文件，每個 consumequeue 文件也是順序寫入，數據格式見下圖。
每個 consumequeue 包含 30 萬個條目，每個條目大小是 20 個位元組，每個文件的大小是 30 萬 * 20 = 60萬位元組，每個文件大小約5.72M 。和 commitlog 文件類似，consumequeue 文件的名稱也是以偏移量來命名的，可以通過消息的邏輯偏移量定位消息位於哪一個文件里。
消費文件按照主題-隊列來保存 ，這種方式特別適配發佈訂閱模型。
消費者從 broker 獲取訂閱消息數據時，不用遍歷整個 commitlog 文件，只需要根據邏輯偏移量從 consumequeue 文件查詢消息偏移量 , 最後通過定位到 commitlog 文件， 獲取真正的消息數據。
這樣就可以簡化消費查詢邏輯，同時因為同一主題下，消費者可以訂閱不同的隊列或者 tag ，同時提高了系統的可擴展性。
4 索引文件
每個消息在業務層面的唯一標識碼要設置到 keys 欄位，方便將來定位消息丟失問題。伺服器會為每個消息創建索引（哈希索引），應用可以通過 topic、key 來查詢這條消息內容，以及消息被誰消費。
由於是哈希索引，請務必保證key儘可能唯一，這樣可以避免潛在的哈希衝突。
//訂單Id
String orderId = "1234567890";
message.setKeys(orderId);
從開源的控制臺中根據主題和 key 查詢消息列表：
進入索引文件目錄 ，如下圖所以：
索引文件名 fileName 是以創建時的時間戳命名的，固定的單個 IndexFile 文件大小約為 400 M 。
IndexFile 的文件邏輯結構類似於 JDK 的 HashMap 的數組加鏈表結構。
索引文件主要由 Header、Slot Table (預設 500 萬個條目)、Index Linked List（預設最多包含 2000萬個條目）三部分組成 。
假如訂單系統發送兩條消息 A 和 B , 他們的 key 都是 "1234567890" ，我們依次存儲消息 A , 消息 B 。
因為這兩個消息的 key 的 hash 值相同，它們對應的哈希槽（深黃色）也會相同，哈希槽會保存的最新的消息 B 的索引條目序號 , 序號值是 4 ，也就是第二個深綠色條目。
而消息 B 的索引條目信息的最後 4 個位元組會保存上一條消息對應的索引條目序號，索引序號值是 3 , 也就是消息 A 。
5 寫到最後
Databases are specializing – the “one size fits all” approach no longer applies ------ MongoDB設計哲學
RocketMQ 存儲模型設計得非常精巧，筆者覺得每種設計都有其底層思考，這裡總結了三點 ：
- 完美適配消息隊列發佈訂閱模型 ；
- 數據文件，消費文件，索引文件各司其職 ，同時以數據文件為核心，非同步構建消費文件 + 索引文件這種模式非常容易擴展到主從複製的架構；
- 充分考慮業務的查詢場景，支持消息 key ，消息 offsetMsgId 查詢消息數據。也支持消費者通過 tag 來訂閱主題下的不同消息，提升了消費者的靈活性。
如果我的文章對你有所幫助，還請幫忙點贊、在看、轉發一下，你的支持會激勵我輸出更高質量的文章，非常感謝！
