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 的數組加鏈表結構。

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 來訂閱主題下的不同消息，提升了消費者的靈活性。

如果我的文章對你有所幫助，還請幫忙點贊、在看、轉發一下，你的支持會激勵我輸出更高質量的文章，非常感謝！