引言

對于一款消息中間件來說，優(yōu)良的數(shù)據(jù)存儲設(shè)計，是實現(xiàn)高性能消息吞吐以及消息查詢的關(guān)鍵所在。因為消息中間件對于外部來說就是發(fā)消息消費消息的一個平臺基礎(chǔ)設(shè)施，但是從其本身來說，需要將海量消息數(shù)據(jù)信息持久化在 RocketMQ 節(jié)點所在的服務器上，這樣即便是服務器斷電，重啟等情況下，也不至于丟失消息數(shù)據(jù)。另外在進行消息消費的時候，RocketMQ 如何能借助自身的存儲設(shè)計快速檢索到對應的消息也是非常重要的，因此本文主要對 RocketMQ 存儲設(shè)計進行了設(shè)計分析。

存儲結(jié)構(gòu)

RocketMQ 對應的存儲文件主要包括三類，分別是 Commitlog 文件、ConsumeQueue 文件以及 Index 文件，每一個文件都有其特殊的使命。

Commitlog 文件

當生產(chǎn)者將消息發(fā)送到 RocketMQ 的 Broker 之后，需要將消息進行持久化存儲，防止消息數(shù)據(jù)丟失。RocketMQ 將消息數(shù)據(jù)寫入存儲文件 CommitLog 中，按照消息的發(fā)送順序?qū)懭胛募斨校總€文件的大小約為 1G，當達到文件大小限制后，就會創(chuàng)建新的 CommitLog 文件。RocketMQ 作為消息中間件來說，最主要的數(shù)據(jù)流程就是基于主題的發(fā)布-訂閱模式進行消息的發(fā)布以及消費，那么當消費者根據(jù)自己訂閱的 Topic 進行消息消費的時候，Broker 怎么在那么多的 CommitLog 文件中找到對應 Topic 的消息數(shù)據(jù)呢？

大家可以想一想，CommitLog 文件中的消息數(shù)據(jù)是一條一條順序?qū)懙?，最笨的方法就是遍歷文件，作為一款高性能的消息中間件，顯然這不是一個好的解決方案。就像從數(shù)據(jù)庫查詢數(shù)據(jù)的時候，遍歷的效率肯定是很低的。那么我們可不可以借助數(shù)據(jù)庫提升數(shù)據(jù)查詢的方式，使用索引來加快消息數(shù)據(jù)的查詢呢？答案是肯定的。就像 MySQL 中的索引本身需要文件保存一樣，在 RocketMQ 中頁有單獨保存索引的文件，就是 ConsumerQueue 文件。

ConsumerQueue 文件

在 RocketMQ 中，每個 Topic 對應多個 MessageQueue，每個 MessageQueue 對應一組 ConsumerQueue 文件索引文件。ConsumerQueue 文件中存儲了消息相對于 CommitLog 文件的 offset 偏移量，CommitLog 文件本身實際上也是通過偏移量來進行命名如第一個文件是 0000000000000，那么第二文件就是消息總量之和 00000001232321，往后新的文件再進行累計。為什么這么做呢？主要就是在進行消息查找的時候根據(jù)消息的偏移量通過二分查找快速定位具體的 CommitLog 文件，提升消息查找效率。需要說明的是，Broker 在進行消息寫入 CommitLog 文件中就會異步將其對應的偏移量寫入 ConsumerQueue 文件中。

在 ConsumerQueue 文件中實際存儲了 CommitLog 文件的 offset 偏移量、消息長度以及 tag 的 hashcode，組成 20 字節(jié)的 block 塊。其在 Broker 上面的存儲路徑大致是：…/store/consumequeue/{topic}/{queueid}/{file}。其中 topic 就是生產(chǎn)中訂閱的主題，因此消費者在消費消息的時候，Broker 會根據(jù)其對應的 Topic 找到對應的 ConsumerQueue 文件，進而找到其索引位置，再到 CommitLog 文件中直接定位具體的消息。

Index 文件

另外 RocketMQ 的特性功能就是可以實現(xiàn)按照消息的屬性進行消息搜索，即建立了索引 Key 的 hashcode 與物理偏移量的映射關(guān)系，根據(jù) key 先快速定義到 commitlog 文件。

存儲性能設(shè)計精髓

上文中為大家闡述了 RocketMQ 關(guān)于存儲結(jié)構(gòu)的設(shè)計，優(yōu)秀的存儲設(shè)計師實現(xiàn)高性能讀寫的前提。那么除了存儲結(jié)構(gòu)的設(shè)計，RocketMQ 也使用了一些性能優(yōu)化手段來實現(xiàn)其強大的消息吞吐能力。

消息順序?qū)?/strong>

前文中說過，消息進入 RocketMQ 之后，消息數(shù)據(jù)是通過順序?qū)懙姆绞铰涞?CommitLog 文件中的。那么這里面就涉及兩個問題，為什么進行順序?qū)懸约笆遣皇侵苯訉懘疟P文件。

1、為什么要順序?qū)懀?/p>
當新的數(shù)據(jù)到來時，只要在之前的文件末尾進行數(shù)據(jù)追加就可以，這樣的數(shù)據(jù)寫入效率要比隨機寫入的效率高。

2、每次數(shù)據(jù)寫入的時候是直接寫磁盤文件嗎？

我們可以反過想，如果每次都是落盤寫入的話實際效率是不高的，無法滿足消息中間件這種高吞吐的性能要求，因此 RocketMQ 實際是借助操作系統(tǒng)的 page cache 來提升寫入效率的，消息并不是直接寫入磁盤，認識先寫入操作系統(tǒng)的 page cache，然后再通過異步刷盤的方式，寫入 CommitLog 文件中，這樣借助順序?qū)懸约跋到y(tǒng)的 page cache 可以時間近乎內(nèi)存的數(shù)據(jù)寫入效率。

同步刷盤和異步刷盤

剛才所說的異步寫入，其實就是 RocketMQ 的異步刷盤模式，但是大家想想這個模式有沒有什么問題。為了提升數(shù)據(jù)吞吐量，消息數(shù)據(jù)過來后，并沒有直接寫盤，而是在系統(tǒng)中的 page cache 中。那么此時如果 Broker 宕機了，那么此時的消息數(shù)據(jù)是容易丟失的。所以雖然異步刷盤的寫入效率高但是也存在數(shù)據(jù)丟失的風險。

1、同步刷盤

在同步刷盤的場景下，當 Broker 接受到對應的消息之后，Broker 將會把這條消息刷入磁盤的 CommitLog 中，才會返回確認消息給生產(chǎn)者。如果在進行消息寫入的時候 Broker 掛了，那么生產(chǎn)者會感受到消息投遞失敗，一般都會都有消息重新發(fā)送的重試邏輯。

這樣看消息似乎不會丟失了，但是由于每次都是先落盤，就會導致數(shù)據(jù)寫入性能下降。

MMAP

在 RocketMQ 中使用了 mmap 技術(shù)來實現(xiàn) Conmmitlog 文件的高性能讀寫，mmap 就是一種內(nèi)存映射文件的方法，對于傳統(tǒng)的文件 IO 交互來說，需要經(jīng)過多次的數(shù)據(jù)復制過程才能將用戶進程的數(shù)據(jù)寫入硬盤或者讀入程序。而 mmap 可以直接將虛擬內(nèi)存中的文件與硬盤中文件地址進行映射，減少了數(shù)據(jù)拷貝的過程，從而提升了數(shù)據(jù)寫入的效率。關(guān)于這部分的內(nèi)容可以參見以前的文章有詳細的介紹。

總結(jié)

本文主要堆 RocketMQ 的存儲設(shè)計進行了分析，圍繞如何實現(xiàn)高性能消息寫入和查詢展開了闡述，希望在分析這些優(yōu)秀中間的具體實現(xiàn)過程中，我們可以將這些優(yōu)秀設(shè)計融入到具體的項目實踐中，當我們遇到類似的問題的時候可以借助于這些設(shè)計思想來解決實際的問題。