簡(jiǎn)介：淺談專有云MQ存儲(chǔ)空間的清理機(jī)制

在近?年的項(xiàng)?保障過(guò)程中，對(duì)專有云MQ產(chǎn)品的存儲(chǔ)?位清理模式?直存疑，總想一探究竟但又苦于工作繁忙、精力有限，直到最近?次項(xiàng)?保障過(guò)程中再次出現(xiàn)了類似的問(wèn)題，?家對(duì)MQ Broker的?位清理機(jī)制仍然?較模糊，于是便有了這篇?章。希望能通過(guò)這篇?章將MQ Broker的消息清理機(jī)制講清楚。
?先，我們先來(lái)看?張MQ的消息保存時(shí)間和Broker磁盤存儲(chǔ)空間的?位趨勢(shì)圖（該圖來(lái)源于銅雀，?前已更名為SRE技術(shù)保障平臺(tái)）。通過(guò)該趨勢(shì)圖，可以看到紅線左側(cè)的消息保存時(shí)間（上?藍(lán)?趨勢(shì)線）和Broker磁盤存儲(chǔ)空間（下?綠?區(qū)域）呈現(xiàn)出規(guī)律性的波動(dòng)。?紅線右側(cè)部分，隨著消息量的快速增加（通過(guò)Broker磁盤存儲(chǔ)空間快速上漲得出），開始?段時(shí)間消息保存時(shí)間還呈規(guī)律性波動(dòng)，但接近最右側(cè)時(shí)，可以看到消息保存時(shí)間的波動(dòng)頻率加快了，?且消息保存時(shí)間快速下降。那么MQ對(duì)消息的清理機(jī)制到底是什么呢？

圖1：消息保存時(shí)間&磁盤空間占比趨勢(shì)圖

在介紹清理機(jī)制前，先來(lái)復(fù)習(xí)?下MQ的消息是如何進(jìn)?存儲(chǔ)的。

圖2：commitlog

Producer發(fā)送的所有消息都存放在Broker節(jié)點(diǎn)的 /home/admin/store/commitlog ?錄下（專有云場(chǎng)景），每個(gè)commitlog的??固定為1G。隨著時(shí)間的推移，當(dāng)Broker接收的消息量越來(lái)越多時(shí)，就會(huì)在該?錄下?成多個(gè)??為1G的commitlog?件。
ps: 特別聲明，雖然該?錄叫commitlog，但?錄中存儲(chǔ)的?件并不是程序?志，?是MQ Broker?來(lái)存儲(chǔ)消息的?件載體，在MQ產(chǎn)品中這種?件載體叫做commitlog。之所以這?做特別說(shuō)明，是因?yàn)闅v史上出現(xiàn)過(guò)由于誤認(rèn)為此?錄下存儲(chǔ)的是程序?志，為了釋放磁盤存儲(chǔ)空間將?錄下的commitlog刪除導(dǎo)致MQ消息丟失的故障。這是?的教訓(xùn)！這個(gè)?錄下的?件不要碰，不要碰，不要碰。
commitlog?錄下的?件讓MQ?行維護(hù)清理便可。那MQ?身是根據(jù)什么規(guī)則來(lái)進(jìn)?清理的呢？先來(lái)看?下MQ???個(gè)?較關(guān)鍵的閾值：

• 72?時(shí)，MQ默認(rèn)的消息保存時(shí)間。從圖1可以看出每次消息保存時(shí)間波動(dòng)下降時(shí)，均會(huì)逼近到該值。
• 凌晨4點(diǎn)，MQ默認(rèn)的消息清理觸發(fā)時(shí)間。從圖1可以看出每次消息保存時(shí)間下降均在凌晨4點(diǎn)發(fā)生。
• 75%，MQ默認(rèn)的開始觸發(fā)清理磁盤存儲(chǔ)空間的閾值。
• 85%，MQ內(nèi)置的開始強(qiáng)制清理磁盤存儲(chǔ)空間的閾值。
• 90%，MQ內(nèi)置的Broker開始禁寫的磁盤存儲(chǔ)空間的閾值。

MQ會(huì)在兩個(gè)時(shí)機(jī)對(duì)commitlog進(jìn)?清理，?是前文提到的每天凌晨4點(diǎn)；另?個(gè)是消息寫?時(shí)。通過(guò)以下表格可以更加清楚的看出具體的清理策略。

清理模式

• 普通清理，這種清理模式只將72?時(shí)之前的commitlog清理掉，MQ在保證存儲(chǔ)72?時(shí)消息的前提下，盡量降低磁盤空間使?率。
• 強(qiáng)制清理，這種清理模式只在Broker存儲(chǔ)空間?于85%的情況下觸發(fā)，此時(shí)MQ在對(duì)commitlog進(jìn)?清理時(shí)，將不再考慮72?時(shí)的消息保留時(shí)間，?是要盡可能保證能夠接收新的MQ消息進(jìn)來(lái)，因此會(huì)強(qiáng)制對(duì) commitlog進(jìn)?清理（因?yàn)槿绻磺謇?#xff0c;磁盤空間使?率進(jìn)?步上漲到90%后，Broker便會(huì)?動(dòng)禁寫，新的消息便?法寫入）。當(dāng)然也不會(huì)?次性將所有的commitlog清理掉，?是只批量清理?部分（代碼中設(shè)置?個(gè)broker?次最多清理10個(gè)commitlog?件）。

我們回過(guò)頭來(lái)再看?下這個(gè)趨勢(shì)圖。

圖3：消息保存時(shí)間&磁盤空間占比趨勢(shì)圖

• 圖中1,2,3,4,5,6 處，Broker的存儲(chǔ)空間均未超過(guò)75%，在每?凌晨4點(diǎn)觸發(fā)了定時(shí)清理，將72?時(shí)之前的消息清理掉。可以看到在清理完成后，消息的保存時(shí)間都回落到了72?時(shí)左右。
• 圖中7處，Broker的存儲(chǔ)空間使?率第?次達(dá)到了75%，但低于85%，觸發(fā)了消息寫?時(shí)的普通清理，此時(shí)清理的還是72?時(shí)之前的消息，可以看到消息保存時(shí)間在清理完成后回落到72?時(shí)左右，但存儲(chǔ)空間使?率下降的?常?，說(shuō)明?前Broker中存儲(chǔ)的消息?部分都是72?時(shí)以內(nèi)產(chǎn)?的。
• 圖中8處，隨著消息的發(fā)送（消息寫?速度?較快），存儲(chǔ)空間使?率第?次達(dá)到了75%，仍低于85%，此時(shí)普通清理仍然是清理72?時(shí)之前的消息數(shù)據(jù)，可以看到磁盤空間使?率并沒(méi)有明顯下降。說(shuō)明此時(shí)消息的寫?速度已經(jīng)?于commitlog的清理速度。
• 8之后發(fā)?的事情，由于此時(shí)消息寫?速度?于commitlog清理速度，雖然消息寫?時(shí)會(huì)觸發(fā)清理動(dòng)作，但此時(shí)Broker中的消息都是72?時(shí)以內(nèi)發(fā)送的，沒(méi)有清理掉任何commitlog，磁盤?位并沒(méi)有降低。隨著消息的不斷寫?，Broker的存儲(chǔ)?位不斷升?，消息的保存時(shí)間基本維持不變。
• 8之后的之后，當(dāng)Broker的存儲(chǔ)?位達(dá)到85%，此時(shí)Broker為了后續(xù)還能繼續(xù)提供服務(wù)，會(huì)開啟強(qiáng)制清理，此時(shí)MQ不再考慮72?時(shí)的消息保留時(shí)間，?是優(yōu)先保證后續(xù)消息的順利寫?，于是會(huì)將72?時(shí)以內(nèi)的消息也進(jìn)?清理。整體表現(xiàn)為Broker的存儲(chǔ)?位達(dá)到85%時(shí)，基本不會(huì)上漲（只有在消息寫?量特別?時(shí)，消息寫?速度遠(yuǎn)遠(yuǎn)?于commitlog清理速度，才會(huì)繼續(xù)上漲），但由于清理了72?時(shí)以內(nèi)的消息，會(huì)使Broker的消息保存時(shí)間開始降低，開始低于72?時(shí)，并隨著后續(xù)清理動(dòng)作不斷降低。

  如上所述，消息寫?量特別?，消息寫?速度遠(yuǎn)?于commitlog的清理速度，Broker的存儲(chǔ)?位在達(dá)到85%后還會(huì)繼續(xù)升?，直至達(dá)到90%時(shí)，Broker為了保護(hù)?身服務(wù)可?性，會(huì)?動(dòng)開啟禁寫，此時(shí)發(fā)送到該Broker的消息會(huì)被拒絕掉。Broker的存儲(chǔ)?位不會(huì)進(jìn)?步上升，?且此時(shí)Broker會(huì)開啟強(qiáng)制清理，對(duì)72?時(shí)以內(nèi)的消息進(jìn)?清理，以便使Broker的存儲(chǔ)?位降到90%以下，使Broker可以重新對(duì)外提供服務(wù)。

ps：實(shí)際在MQ的代碼實(shí)現(xiàn)層?，為了保證消息寫?Broker的性能，并不是每次寫?消息時(shí)都進(jìn)?存儲(chǔ)
空間檢查和commitlog清理，?是通過(guò)定時(shí)任務(wù)來(lái)執(zhí)?（該定時(shí)任務(wù)每10s執(zhí)??次）。

上述介紹的?個(gè)清理閾值中，有些是可調(diào)的，有些是內(nèi)置在代碼中不可調(diào)的。?如“凌晨4點(diǎn)”，“72?時(shí)”，“75%”，這3個(gè)參數(shù)是?戶可以調(diào)整的MQ配置，“85%”，“90%”是寫死在代碼中的，是?法調(diào)整的。
查看Broker配置信息的?式如下，在Broker的docker中執(zhí)?

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

• deleteWhen，對(duì)應(yīng)“凌晨4點(diǎn)”
• fileReservedTime，對(duì)應(yīng)“72?時(shí)”
• diskMaxUsedSpaceRatio，對(duì)應(yīng)“75%”

在調(diào)整配置時(shí)，deleteWhen通常選在客戶MQ業(yè)務(wù)的低峰期進(jìn)?，盡量避免commitlog清理對(duì)?產(chǎn)業(yè)務(wù)的影響。當(dāng)Broker存儲(chǔ)?位出現(xiàn)快速上漲時(shí)，為避免存儲(chǔ)?位達(dá)到90%，出現(xiàn)禁寫影響?產(chǎn)業(yè)務(wù)的情況，需要同時(shí)調(diào)整fileReservedTime和diskMaxUsedSpaceRatio的默認(rèn)設(shè)置，通過(guò)調(diào)整這兩個(gè)參數(shù)共同作?保證Broker的存儲(chǔ)空間可以及時(shí)得到清理（還有?種降?位的?式——關(guān)閉MQ消息軌跡）。當(dāng)然這所有參數(shù)的調(diào)整都需要經(jīng)過(guò)與產(chǎn)研的溝通與確認(rèn)。

以上就是對(duì)MQ Broker消息清理機(jī)制的剖析，希望通過(guò)這篇?章能夠讓大家理解并掌握其清理機(jī)制，能夠處理實(shí)際工作中遇到的MQ Broker存儲(chǔ)?位快速上漲的問(wèn)題。

我們是阿里云智能全球技術(shù)服務(wù)-SRE團(tuán)隊(duì)，我們致力成為一個(gè)以技術(shù)為基礎(chǔ)、面向服務(wù)、保障業(yè)務(wù)系統(tǒng)高可用的工程師團(tuán)隊(duì)；提供專業(yè)、體系化的SRE服務(wù)，幫助廣大客戶更好地使用云、基于云構(gòu)建更加穩(wěn)定可靠的業(yè)務(wù)系統(tǒng)，提升業(yè)務(wù)穩(wěn)定性。我們期望能夠分享更多幫助企業(yè)客戶上云、用好云，讓客戶云上業(yè)務(wù)運(yùn)行更加穩(wěn)定可靠的技術(shù)，您可用釘釘掃描下方二維碼，加入阿里云SRE技術(shù)學(xué)院釘釘圈子，和更多云上人交流關(guān)于云平臺(tái)的那些事。

原文鏈接：https://developer.aliyun.com/article/782706?

版權(quán)聲明：本文內(nèi)容由阿里云實(shí)名注冊(cè)用戶自發(fā)貢獻(xiàn)，版權(quán)歸原作者所有，阿里云開發(fā)者社區(qū)不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。具體規(guī)則請(qǐng)查看《阿里云開發(fā)者社區(qū)用戶服務(wù)協(xié)議》和《阿里云開發(fā)者社區(qū)知識(shí)產(chǎn)權(quán)保護(hù)指引》。如果您發(fā)現(xiàn)本社區(qū)中有涉嫌抄襲的內(nèi)容，填寫侵權(quán)投訴表單進(jìn)行舉報(bào)，一經(jīng)查實(shí)，本社區(qū)將立刻刪除涉嫌侵權(quán)內(nèi)容。

總結(jié)

以上是生活随笔為你收集整理的浅谈专有云MQ存储空间的清理机制的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。