RocketMQ簡(jiǎn)介

RocketMQ有Producer、Consumer、NameSrv、Broker四個(gè)部分。其中Broker用于存儲(chǔ)消息，維護(hù)消息隊(duì)列和訂閱關(guān)系，是RocketMQ四個(gè)部分中最重要的一個(gè)部分，并且RocketMQ的高性能就是依賴于Broker模塊的底層存儲(chǔ)模型實(shí)現(xiàn)的。所以搞清楚Broker的存儲(chǔ)模型是學(xué)習(xí)RocketMQ最重要的一步。

RocketMQ 優(yōu)異的性能表現(xiàn)，必然繞不開其優(yōu)秀的存儲(chǔ)模型 。

這篇文章，筆者按照自己的理解 , 嘗試分析 RocketMQ 的存儲(chǔ)模型，希望對(duì)大家有所啟發(fā)。

1 整體概覽

首先溫習(xí)下 RocketMQ 架構(gòu)。

整體架構(gòu)中包含四種角色 :

• Producer ：消息發(fā)布的角色，Producer 通過 MQ 的負(fù)載均衡模塊選擇相應(yīng)的 Broker 集群隊(duì)列進(jìn)行消息投遞，投遞的過程支持快速失敗并且低延遲。
• Consumer ：消息消費(fèi)的角色，支持以 push 推，pull 拉兩種模式對(duì)消息進(jìn)行消費(fèi)。
• NameServer ：名字服務(wù)是一個(gè)非常簡(jiǎn)單的 Topic 路由注冊(cè)中心，其角色類似 Dubbo 中的 zookeeper ，支持 Broker 的動(dòng)態(tài)注冊(cè)與發(fā)現(xiàn)。
• BrokerServer ：Broker 主要負(fù)責(zé)消息的存儲(chǔ)、投遞和查詢以及服務(wù)高可用保證 。

本文的重點(diǎn)在于分析 BrokerServer 的消息存儲(chǔ)模型。我們先進(jìn)入 broker 的文件存儲(chǔ)目錄 。

消息存儲(chǔ)和下面三個(gè)文件關(guān)系非常緊密：

1. 數(shù)據(jù)文件 commitlog

消息主體以及元數(shù)據(jù)的存儲(chǔ)主體 ；

1. 消費(fèi)文件 consumequeue

消息消費(fèi)隊(duì)列，引入的目的主要是提高消息消費(fèi)的性能 ；

1. 索引文件 index

索引文件，提供了一種可以通過 key 或時(shí)間區(qū)間來查詢消息。

RocketMQ 采用的是混合型的存儲(chǔ)結(jié)構(gòu)，Broker 單個(gè)實(shí)例下所有的隊(duì)列共用一個(gè)數(shù)據(jù)文件（commitlog）來存儲(chǔ)。

生產(chǎn)者發(fā)送消息至 Broker 端，然后 Broker 端使用同步或者異步的方式對(duì)消息刷盤持久化，保存至 commitlog 文件中。只要消息被刷盤持久化至磁盤文件 commitlog 中，那么生產(chǎn)者發(fā)送的消息就不會(huì)丟失。

Broker 端的后臺(tái)服務(wù)線程會(huì)不停地分發(fā)請(qǐng)求并異步構(gòu)建 consumequeue（消費(fèi)文件）和 indexFile（索引文件）。

2 數(shù)據(jù)文件

RocketMQ 的消息數(shù)據(jù)都會(huì)寫入到數(shù)據(jù)文件中， 我們稱之為 commitlog 。

所有的消息都會(huì)順序?qū)懭霐?shù)據(jù)文件，當(dāng)文件寫滿了，會(huì)寫入下一個(gè)文件。

如上圖所示，單個(gè)文件大小默認(rèn) 1G , 文件名長(zhǎng)度為 20 位，左邊補(bǔ)零，剩余為起始偏移量，比如 00000000000000000000 代表了第一個(gè)文件，起始偏移量為 0 ，文件大小為1 G = 1073741824。

當(dāng)?shù)谝粋€(gè)文件寫滿了，第二個(gè)文件為 00000000001073741824，起始偏移量為 1073741824，以此類推。

從上圖中，我們可以看到消息是一條一條寫入到文件，每條消息的格式是固定的。

這樣設(shè)計(jì)有三點(diǎn)優(yōu)勢(shì)：

• 順序?qū)?/li>

磁盤的存取速度相對(duì)內(nèi)存來講并不快，一次磁盤 IO 的耗時(shí)主要取決于：尋道時(shí)間和盤片旋轉(zhuǎn)時(shí)間，提高磁盤 IO 性能最有效的方法就是：減少隨機(jī) IO，增加順序 IO 。

《 The Pathologies of Big Data 》這篇文章指出：內(nèi)存隨機(jī)讀寫的速度遠(yuǎn)遠(yuǎn)低于磁盤順序讀寫的速度。磁盤順序?qū)懭胨俣瓤梢赃_(dá)到幾百兆/s，而隨機(jī)寫入速度只有幾百 KB /s，相差上千倍。

• 快速定位

因?yàn)橄⑹且粭l一條寫入到 commitlog 文件 ，寫入完成后，我們可以得到這條消息的物理偏移量。

每條消息的物理偏移量是唯一的， commitlog 文件名是遞增的，可以根據(jù)消息的物理偏移量通過二分查找，定位消息位于那個(gè)文件中，并獲取到消息實(shí)體數(shù)據(jù)。

• 通過消息 offsetMsgId 查詢消息數(shù)據(jù)

消息 offsetMsgId 是由 Broker 服務(wù)端在寫入消息時(shí)生成的 ，該消息包含兩個(gè)部分：

• Broker 服務(wù)端 ip + port 8個(gè)字節(jié)；
• commitlog 物理偏移量 8個(gè)字節(jié) 。

我們可以通過消息 offsetMsgId ，定位到 Broker 的 ip 地址 + 端口 ，傳遞物理偏移量參數(shù) ，即可定位該消息實(shí)體數(shù)據(jù)。

3 消費(fèi)文件

在介紹 consumequeue 文件之前， 我們先溫習(xí)下消息隊(duì)列的傳輸模型-發(fā)布訂閱模型 ， 這也是 RocketMQ 當(dāng)前的傳輸模型。

發(fā)布訂閱模型具有如下特點(diǎn)：

• 消費(fèi)獨(dú)立：相比隊(duì)列模型的匿名消費(fèi)方式，發(fā)布訂閱模型中消費(fèi)方都會(huì)具備的身份，一般叫做訂閱組（訂閱關(guān)系），不同訂閱組之間相互獨(dú)立不會(huì)相互影響。
• 一對(duì)多通信：基于獨(dú)立身份的設(shè)計(jì)，同一個(gè)主題內(nèi)的消息可以被多個(gè)訂閱組處理，每個(gè)訂閱組都可以拿到全量消息。因此發(fā)布訂閱模型可以實(shí)現(xiàn)一對(duì)多通信。

因此，rocketmq 的文件設(shè)計(jì)必須滿足發(fā)布訂閱模型的需求。

那么僅僅 commitlog 文件是否可以滿足需求嗎 ？

假如有一個(gè) consumerGroup 消費(fèi)者，訂閱主題 my-mac-topic ，因?yàn)?commitlog 包含所有的消息數(shù)據(jù)，查詢?cè)撝黝}下的消息數(shù)據(jù)，需要遍歷數(shù)據(jù)文件 commitlog , 這樣的效率是極其低下的。

進(jìn)入 rocketmq 存儲(chǔ)目錄，顯示見下圖：

• 消費(fèi)文件按照主題存儲(chǔ)，每個(gè)主題下有不同的隊(duì)列，圖中 my-mac-topic 有 16 個(gè)隊(duì)列 ;
• 每個(gè)隊(duì)列目錄下 ，存儲(chǔ) consumequeue 文件，每個(gè) consumequeue 文件也是順序?qū)懭?，?shù)據(jù)格式見下圖。

每個(gè) consumequeue 包含 30 萬(wàn)個(gè)條目，每個(gè)條目大小是 20 個(gè)字節(jié)，每個(gè)文件的大小是 30 萬(wàn) * 20 = 60萬(wàn)字節(jié)，每個(gè)文件大小約5.72M 。和 commitlog 文件類似，consumequeue 文件的名稱也是以偏移量來命名的，可以通過消息的邏輯偏移量定位消息位于哪一個(gè)文件里。

消費(fèi)文件按照主題-隊(duì)列來保存 ，這種方式特別適配發(fā)布訂閱模型。

消費(fèi)者從 broker 獲取訂閱消息數(shù)據(jù)時(shí)，不用遍歷整個(gè) commitlog 文件，只需要根據(jù)邏輯偏移量從 consumequeue 文件查詢消息偏移量 , 最后通過定位到 commitlog 文件， 獲取真正的消息數(shù)據(jù)。

這樣就可以簡(jiǎn)化消費(fèi)查詢邏輯，同時(shí)因?yàn)橥恢黝}下，消費(fèi)者可以訂閱不同的隊(duì)列或者 tag ，同時(shí)提高了系統(tǒng)的可擴(kuò)展性。

4 索引文件

每個(gè)消息在業(yè)務(wù)層面的唯一標(biāo)識(shí)碼要設(shè)置到 keys 字段，方便將來定位消息丟失問題。服務(wù)器會(huì)為每個(gè)消息創(chuàng)建索引（哈希索引），應(yīng)用可以通過 topic、key 來查詢這條消息內(nèi)容，以及消息被誰(shuí)消費(fèi)。

由于是哈希索引，請(qǐng)務(wù)必保證key盡可能唯一，這樣可以避免潛在的哈希沖突。

//訂單Id   
String orderId = "1234567890";   
message.setKeys(orderId);   

從開源的控制臺(tái)中根據(jù)主題和 key 查詢消息列表：

進(jìn)入索引文件目錄 ，如下圖所以：

索引文件名 fileName 是以創(chuàng)建時(shí)的時(shí)間戳命名的，固定的單個(gè) IndexFile 文件大小約為 400 M 。

IndexFile 的文件邏輯結(jié)構(gòu)類似于 JDK 的 HashMap 的數(shù)組加鏈表結(jié)構(gòu)。

索引文件主要由 Header、Slot Table (默認(rèn) 500 萬(wàn)個(gè)條目)、Index Linked List（默認(rèn)最多包含 2000萬(wàn)個(gè)條目）三部分組成 。

假如訂單系統(tǒng)發(fā)送兩條消息 A 和 B , 他們的 key 都是 "1234567890" ，我們依次存儲(chǔ)消息 A , 消息 B 。

因?yàn)檫@兩個(gè)消息的 key 的 hash 值相同，它們對(duì)應(yīng)的哈希槽（深黃色）也會(huì)相同，哈希槽會(huì)保存的最新的消息 B 的索引條目序號(hào) , 序號(hào)值是 4 ，也就是第二個(gè)深綠色條目。

而消息 B 的索引條目信息的最后 4 個(gè)字節(jié)會(huì)保存上一條消息對(duì)應(yīng)的索引條目序號(hào)，索引序號(hào)值是 3 , 也就是消息 A 。

5 寫到最后

Databases are specializing – the “one size fits all” approach no longer applies ------ MongoDB設(shè)計(jì)哲學(xué)

RocketMQ 存儲(chǔ)模型設(shè)計(jì)得非常精巧，筆者覺得每種設(shè)計(jì)都有其底層思考，這里總結(jié)了三點(diǎn) ：

• 完美適配消息隊(duì)列發(fā)布訂閱模型 ；
• 數(shù)據(jù)文件，消費(fèi)文件，索引文件各司其職 ，同時(shí)以數(shù)據(jù)文件為核心，異步構(gòu)建消費(fèi)文件 + 索引文件這種模式非常容易擴(kuò)展到主從復(fù)制的架構(gòu)；
• 充分考慮業(yè)務(wù)的查詢場(chǎng)景，支持消息 key ，消息 offsetMsgId 查詢消息數(shù)據(jù)。也支持消費(fèi)者通過 tag 來訂閱主題下的不同消息，提升了消費(fèi)者的靈活性。

到此這篇關(guān)于終于弄明白了 RocketMQ 的存儲(chǔ)模型的文章就介紹到這了,更多相關(guān) RocketMQ 存儲(chǔ)模型內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論