我們知道RocketMQ主要分為消息 生產、存儲（消息堆積）、消費 三大塊領域。

那接下來，我們白話一下，RocketMQ是如何存儲消息的，揭秘消息存儲全過程。

注意，如果白話中不小心提到相關代碼配置與類名，請參考RocketMQ 4.9.4版本

• 存儲模型與存儲類型
• 如何保證存儲消息不丟失
• 如何提高寫入性能
• 如何清理過期消息

存儲模型是什么？有哪些存儲類型？

RocketMQ使用了一種基于日志的存儲方式，將消息以順序寫入的方式追加到文件中，從而實現高性能的消息存儲和讀取。

RocketMQ的消息存儲方式可以分為兩個類型：CommitLog 和ConsumeQueue 。

圖片

還有一個文件類型是indexfile，主要用于控制臺消息檢索，不影響消息的寫入與消費，我們就不展開了。

CommitLog

CommitLog文件存儲了Producer端寫入的消息主體內容，它以追加寫入的方式將消息存儲到磁盤上的文件中。

單個文件大小默認1G ，文件名長度為20位（左邊補零，剩余為起始偏移量），當文件滿了，寫入下一個文件。

比如00000000000000000000代表了第一個文件，起始偏移量為0，文件大小為1G=1073741824；當第一個文件寫滿了，第二個文件為00000000001073741824，起始偏移量為1073741824，以此類推。

它的主要特點是：順序寫，但是隨機讀（被ConsumeQueue讀取）。

雖然是隨機讀，但是利用package機制，可以批量地從磁盤讀取，作為cache存到內存中，加速后續的讀取速度。

Broker單個實例下所有的隊列共用一個日志數據文件CommitLog來存儲。而Kafka采用的是獨立型的存儲結構，每個隊列一個文件。

ConsumeQueue

ConsumeQueue文件是用于支持消息消費的存儲結構。保存了指定Topic下的隊列消息在CommitLog中的起始物理偏移量offset，消息大小size和消息Tag的HashCode值。

消費者 通過 順序讀取 ConsumeQueue文件，可以快速定位到消息在CommitLog中的物理存儲位置，從而實現快速消息的拉取和消費。

從實際物理存儲的角度來看，每個主題Topic下的每個隊列Queue對應一個ConsumeQueue文件。

生產者端的消息是順序寫入CommitLog，消費者端是順序讀取ConsumeQueue。但是根據ConsumeQueue的起始物理位置偏移量offset讀取消息真實內容，實際是隨機讀取CommitLog。實現了 消息生產與消息消費、數據存儲和數據索引 相互分離。

怎么保證存儲消息不丟失？

刷盤機制

Broker在把消息寫入日志文件的過程中，如果在剛收到消息時，Broker異常宕機了，那么內存中尚未寫入磁盤的消息就會丟失了。

因此，RocketMQ持久化消息分為兩種：同步刷盤和異步刷盤（默認配置）。

異步刷盤是指Broker收到消息后先存儲到PageCache，然后立即通知Producer消息已存儲成功，可以繼續處理業務邏輯。此后，Broker會啟動一個異步線程將消息持久化到磁盤。然而，如果Broker在持久化到磁盤之前發生故障，消息將會丟失。

## 刷盤策略配置
flushDiskType = ASYNC_FLUSH

注意，寫入PageCache后，應用服務宕機消息不丟失，只有機器斷電或宕機會有少量消息丟失。

相比之下，同步刷盤的方式是在消息存儲到緩存后不立即通知Producer，而是等待消息被持久化到磁盤后再通知Producer。這種方式確保了消息不會丟失，但性能不如異步刷盤高。一般用于金融業務。

## 刷盤策略配置
flushDiskType = SYNC_FLUSH

在選擇刷盤方式時，需要根據業務場景進行權衡。

主從同步機制

即使Broker采用同步刷盤策略，但如果刷盤完成后磁盤損壞，會導致所有存儲在磁盤上的消息丟失。

即使采用了主從復制，如果主節點在刷盤完成后還沒有來得及將數據同步給從節點就發生了磁盤故障，同樣會導致數據丟失。

所以我們可以配置同步機制，等待從節點復制完成主節點的消息后，才去通知Producer完成了消息存儲。

## 主從同步策略配置
brokerRole=SYNC_MASTER

怎么提高存儲寫入性能？

零拷貝技術

RocketMQ通過使用內存映射文件（包括CommitLog、 ConsumeQueue等文件）來提高IO訪問性能，也就是我們常說的零拷貝技術。

Java在NIO包里，引入了sendFile（FileChannel類）和MMAP（MappedByteBuffer類）兩種實現方式的零拷貝技術。

主流的MQ都會使用零拷貝技術，來提升IO：

• Kafka：record 的讀和寫都是基于 FileChannel。index 的讀寫則基于 MMAP。
• RocketMQ：讀取數據基于 MMAP，寫入數據默認使用 MMAP。但可以通過修改配置transientStorePoolEnable參數將其配置為使用 FileChannel。作者之所以這樣設計，是為了避免 PageCache 的鎖競爭，并通過兩層架構實現讀寫分離。

緩沖池寫入增強

在不開啟RocketMQ的內存映射增強方案時，RocketMQ的讀和寫都只會簡單直接使用MMAP。

但是，MappedByteBuffer也存在一些缺陷：

• 使用虛擬內存，超過物理內存會導致內存交換，引起磁盤IO（可能非順序IO）速度較慢。
• 虛擬內存交換是受操作系統控制的，所以其他進程活動也會觸發RocketMQ內存映射的交換。
• 文件內存映射寫入PageCache時存在鎖競爭，直接寫入內存可避免競爭，在異步刷盤場景下速度更快。

為此，RocketMQ通過transientStorePoolEnable參數控制，對寫入進行了優化。

如果開啟了這個參數，會將寫入拆分為兩步， 寫入緩沖區 + 異步刷盤 的增強策略。

## 刷盤策略配置
flushDiskType = ASYNC_FLUSH 
transientStorePoolEnable = true

MappedFile會提前申請一塊直接內存用作緩沖區，放棄使用mmap直接寫文件。

數據先寫入緩沖區，然后異步線程每200ms（且臟數據達到16K，commitCommitLogLeastPages = 4）將緩沖區的數據commit寫入FileChannel。

再喚醒定時服務（FlushRealTimeService類）將FileChannel里的數據持久化到磁盤。flush函數和commit一樣也可以傳入一個刷盤頁數，當臟頁數量達到16K時(flushLeastPages = 4)，會進行刷盤操作，調用FileChannel的force將內存中的數據持久化到磁盤。

開啟transientStorePoolEnable參數后，性能最好，但是相對來說持久化最不可靠

如何處理消息的過期和刪除？

RocketMQ 使用存儲時長作為消息存儲的依據，即每個節點對外承諾消息的存儲時長。在存儲時長范圍內的消息都會被保留，無論消息是否被消費；超過時長限制的消息則會被清理掉。

需要注意的是，在RocketMQ中，消息存儲時長并不能完整控制消息的實際保存時間。

因為消息存儲仍然使用本地磁盤，本地磁盤空間不足時，為保證服務穩定性消息仍然會被強制清理，導致消息的實際保存時長小于設置的保存時長。

建議在存儲成本可控的前提下，盡可能延長消息存儲時長。延長消息存儲時長，可以為緊急故障恢復、應急問題排查和消息回溯帶來更多的可操作空間。

總結

• 存儲模型與存儲類型：commitLog文件存儲消息物理文件，consumeQueue文件夾存儲邏輯隊列索引
• 如何保證存儲消息不丟失：同步&異步刷盤、主從消息同步
• 如何提高寫入性能：零拷貝技術MMAP和FileChannel、緩沖區增強 + 異步刷盤 策略
• 如何清理過期消息：按存儲時長清理消息