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

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

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

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

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

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

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

圖片

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

CommitLog

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

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

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

它的主要特點是：順序寫，但是隨機讀（被ConsumeQueue讀?。?/p>

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

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

ConsumeQueue

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

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

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

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

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

刷盤機制

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

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

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

## 刷盤策略配置
flushDiskType = ASYNC_FLUSH

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

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

## 刷盤策略配置
flushDiskType = SYNC_FLUSH

在選擇刷盤方式時，需要根據(jù)業(yè)務場景進行權衡。

主從同步機制

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

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

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

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

怎么提高存儲寫入性能？

零拷貝技術

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

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

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

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

緩沖池寫入增強

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

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

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

為此，RocketMQ通過transientStorePoolEnable參數(shù)控制，對寫入進行了優(yōu)化。

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

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

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

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

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

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

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

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

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

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

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

總結

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