浅谈专有云MQ存储空间的清理机制
在近?年的項(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ǔ)空間快速上漲得出),開(kāi)始?段時(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)的開(kāi)始觸發(fā)清理磁盤存儲(chǔ)空間的閾值。
- 85%,MQ內(nèi)置的開(kāi)始強(qiáng)制清理磁盤存儲(chǔ)空間的閾值。
- 90%,MQ內(nèi)置的Broker開(kāi)始禁寫的磁盤存儲(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ì)開(kāi)啟強(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í)間開(kāi)始降低,開(kāi)始低于72?時(shí),并隨著后續(xù)清理動(dòng)作不斷降低。
如上所述,消息寫?量特別?,消息寫?速度遠(yuǎn)?于commitlog的清理速度,Broker的存儲(chǔ)?位在達(dá)到85%后還會(huì)繼續(xù)升?,直至達(dá)到90%時(shí),Broker為了保護(hù)?身服務(wù)可?性,會(huì)?動(dòng)開(kāi)啟禁寫,此時(shí)發(fā)送到該Broker的消息會(huì)被拒絕掉。Broker的存儲(chǔ)?位不會(huì)進(jìn)?步上升,?且此時(shí)Broker會(huì)開(kāi)啟強(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í)?
- 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)歸原作者所有,阿里云開(kāi)發(fā)者社區(qū)不擁有其著作權(quán),亦不承擔(dān)相應(yīng)法律責(zé)任。具體規(guī)則請(qǐng)查看《阿里云開(kāi)發(fā)者社區(qū)用戶服務(wù)協(xié)議》和《阿里云開(kāi)發(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)題。
- 上一篇: OpenKruise v0.8.0 版本
- 下一篇: 三只松鼠:阿里云数据中台基座上的多渠道、