淺談專有云MQ存儲空間的清理機制

簡介： 淺談專有云MQ存儲空間的清理機制

在近⼀年的項⽬保障過程當中，對專有云MQ產品的存儲⽔位清理模式⼀直存疑，總想一探究竟但又苦於工做繁忙、精力有限，直到最近⼀次項⽬保障過程當中再次出現了相似的問題，⼤家對MQ Broker的⽔位清理機制仍然⽐較模糊，因而便有了這篇⽂章。但願能經過這篇⽂章將MQ Broker的消息清理機制講清楚。
⾸先，咱們先來看⼀張MQ的消息保存時間和Broker磁盤存儲空間的⽔位趨勢圖（該圖來源於銅雀，⽬前已改名爲SRE技術保障平臺）。經過該趨勢圖，能夠看到紅線左側的消息保存時間（上⽅藍⾊趨勢線）和Broker磁盤存儲空間（下⽅綠⾊區域）呈現出規律性的波動。⽽紅線右側部分，隨着消息量的快速增長（經過Broker磁盤存儲空間快速上漲得出），開始⼀段時間消息保存時間還呈規律性波動，但接近最右側時，能夠看到消息保存時間的波動頻率加快了，⽽且消息保存時間快速降低。那麼MQ對消息的清理機制究竟是什麼呢？

圖1：消息保存時間&磁盤空間佔比趨勢圖

在介紹清理機制前，先來複習⼀下MQ的消息是如何進⾏存儲的。

圖2：commitlog

Producer發送的全部消息都存放在Broker節點的
/home/admin/store/commitlog ⽬錄下（專有云場景），每一個commitlog的⼤⼩固定爲1G。隨着時間的推移，當Broker接收的消息量愈來愈多時，就會在該⽬錄下⽣成多個⼤⼩爲1G的commitlog⽂件。
ps: 特別聲明，雖然該⽬錄叫commitlog，但⽬錄中存儲的⽂件並非程序⽇志，⽽是MQ Broker⽤來存儲消息的⽂件載體，在MQ產品中這種⽂件載體叫作commitlog。之因此這⾥作特別說明，是由於歷史上出現過因爲誤認爲此⽬錄下存儲的是程序⽇志，爲了釋放磁盤存儲空間將⽬錄下的commitlog刪除致使MQ消息丟失的故障。這是⾎的教訓！這個⽬錄下的⽂件不要碰，不要碰，不要碰。
commitlog⽬錄下的⽂件讓MQ⾃行維護清理即可。那MQ⾃身是根據什麼規則來進⾏清理的呢？先來看⼀下MQ⾥⾯⼏個⽐較關鍵的閾值：

• 72⼩時，MQ默認的消息保存時間。從圖1能夠看出每次消息保存時間波動降低時，均會逼近到該值。
• 凌晨4點，MQ默認的消息清理觸發時間。從圖1能夠看出每次消息保存時間降低均在凌晨4點發生。
• 75%，MQ默認的開始觸發清理磁盤存儲空間的閾值。
• 85%，MQ內置的開始強制清理磁盤存儲空間的閾值。
• 90%，MQ內置的Broker開始禁寫的磁盤存儲空間的閾值。

MQ會在兩個時機對commitlog進⾏清理，⼀是前文提到的天天凌晨4點；另⼀個是消息寫⼊時。經過如下表格能夠更加清楚的看出具體的清理策略。

清理模式

• 普通清理，這種清理模式只將72⼩時以前的commitlog清理掉，MQ在保證存儲72⼩時消息的前提下，儘可能下降磁盤空間使⽤率。
• 強制清理，這種清理模式只在Broker存儲空間⾼於85%的狀況下觸發，此時MQ在對commitlog進⾏清理時，將再也不考慮72⼩時的消息保留時間，⽽是要儘量保證可以接收新的MQ消息進來，所以會強制對 commitlog進⾏清理（由於若是不清理，磁盤空間使⽤率進⼀步上漲到90%後，Broker便會⾃動禁寫，新的消息便⽆法寫入）。固然也不會⼀次性將全部的commitlog清理掉，⽽是隻批量清理⼀部分（代碼中設置⼀個broker⼀次最多清理10個commitlog⽂件）。

咱們回過頭來再看⼀下這個趨勢圖。

圖3：消息保存時間&磁盤空間佔比趨勢圖

• 圖中1,2,3,4,5,6 處，Broker的存儲空間均未超過75%，在每⽇凌晨4點觸發了定時清理，將72⼩時以前的消息清理掉。能夠看到在清理完成後，消息的保存時間都回落到了72⼩時左右。
• 圖中7處，Broker的存儲空間使⽤率第⼀次達到了75%，但低於85%，觸發了消息寫⼊時的普通清理，此時清理的仍是72⼩時以前的消息，能夠看到消息保存時間在清理完成後回落到72⼩時左右，但存儲空間使⽤率降低的⾮常⼩，說明⽬前Broker中存儲的消息⼤部分都是72⼩時之內產⽣的。
• 圖中8處，隨着消息的發送（消息寫⼊速度⽐較快），存儲空間使⽤率第⼆次達到了75%，仍低於85%，此時普通清理仍然是清理72⼩時以前的消息數據，能夠看到磁盤空間使⽤率並無明顯降低。說明此時消息的寫⼊速度已經⾼於commitlog的清理速度。
• 8以後發⽣的事情，因爲此時消息寫⼊速度⾼於commitlog清理速度，雖然消息寫⼊時會觸發清理動做，但此時Broker中的消息都是72⼩時之內發送的，沒有清理掉任何commitlog，磁盤⽔位並無下降。隨着消息的不斷寫⼊，Broker的存儲⽔位不斷升⾼，消息的保存時間基本維持不變。
• 8以後的以後，當Broker的存儲⽔位達到85%，此時Broker爲了後續還能繼續提供服務，會開啓強制清理，此時MQ再也不考慮72⼩時的消息保留時間，⽽是優先保證後續消息的順利寫⼊，因而會將72⼩時之內的消息也進⾏清理。總體表現爲Broker的存儲⽔位達到85%時，基本不會上漲（只有在消息寫⼊量特別⼤時，消息寫⼊速度遠遠⼤於commitlog清理速度，纔會繼續上漲），但因爲清理了72⼩時之內的消息，會使Broker的消息保存時間開始下降，開始低於72⼩時，並隨着後續清理動做不斷下降。
• 如上所述，消息寫⼊量特別⼤，消息寫⼊速度遠⾼於commitlog的清理速度，Broker的存儲⽔位在達到85%後還會繼續升⾼，直至達到90%時，Broker爲了保護⾃身服務可⽤性，會⾃動開啓禁寫，此時發送到該Broker的消息會被拒絕掉。Broker的存儲⽔位不會進⼀步上升，⽽且此時Broker會開啓強制清理，對72⼩時之內的消息進⾏清理，以便使Broker的存儲⽔位降到90%如下，使Broker能夠從新對外提供服務。

ps：實際在MQ的代碼實現層⾯，爲了保證消息寫⼊Broker的性能，並非每次寫⼊消息時都進⾏存儲
空間檢查和commitlog清理，⽽是經過定時任務來執⾏（該定時任務每10s執⾏⼀次）。

上述介紹的⼏個清理閾值中，有些是可調的，有些是內置在代碼中不可調的。⽐如「凌晨4點」，「72⼩時」，「75%」，這3個參數是⽤戶能夠調整的MQ配置，「85%」，「90%」是寫死在代碼中的，是⽆法調整的。
查看Broker配置信息的⽅式以下，在Broker的docker中執⾏

sh /home/admin/rmq/bin/mqadmin getBrokerConfig -b ${IP}:10911

• deleteWhen，對應「凌晨4點」
• fileReservedTime，對應「72⼩時」
• diskMaxUsedSpaceRatio，對應「75%」

在調整配置時，deleteWhen一般選在客戶MQ業務的低峯期進⾏，儘可能避免commitlog清理對⽣產業務的影響。當Broker存儲⽔位出現快速上漲時，爲避免存儲⽔位達到90%，出現禁寫影響⽣產業務的狀況，須要同時調整fileReservedTime和diskMaxUsedSpaceRatio的默認設置，經過調整這兩個參數共同做⽤保證Broker的存儲空間能夠及時獲得清理（還有⼀種降⽔位的⽅式——關閉MQ消息軌跡）。固然這全部參數的調整都須要通過與產研的溝通與確認。

以上就是對MQ Broker消息清理機制的剖析，但願經過這篇⽂章可以讓你們理解並掌握其清理機制，可以處理實際工做中遇到的MQ Broker存儲⽔位快速上漲的問題。

咱們是阿里雲智能全球技術服務-SRE團隊，咱們致力成爲一個以技術爲基礎、面向服務、保障業務系統高可用的工程師團隊；提供專業、體系化的SRE服務，幫助廣大客戶更好地使用雲、基於雲構建更加穩定可靠的業務系統，提高業務穩定性。

做者：劉維
原文連接本文爲阿里雲原創內容，未經容許不得轉載