如何管理建好的网站,单屏风格wordpress主题,建立网站花钱吗,html静态网页制作案例简介#xff1a; 浅谈专有云MQ存储空间的清理机制 在近⼀年的项⽬保障过程中#xff0c;对专有云MQ产品的存储⽔位清理模式⼀直存疑#xff0c;总想一探究竟但又苦于工作繁忙、精力有限#xff0c;直到最近⼀次项⽬保障过程中再次出现了类似的问题#xff0c;⼤家对MQ Bro… 简介 浅谈专有云MQ存储空间的清理机制 在近⼀年的项⽬保障过程中对专有云MQ产品的存储⽔位清理模式⼀直存疑总想一探究竟但又苦于工作繁忙、精力有限直到最近⼀次项⽬保障过程中再次出现了类似的问题⼤家对MQ Broker的⽔位清理机制仍然⽐较模糊于是便有了这篇⽂章。希望能通过这篇⽂章将MQ Broker的消息清理机制讲清楚。 ⾸先我们先来看⼀张MQ的消息保存时间和Broker磁盘存储空间的⽔位趋势图该图来源于铜雀⽬前已更名为SRE技术保障平台。通过该趋势图可以看到红线左侧的消息保存时间上⽅蓝⾊趋势线和Broker磁盘存储空间下⽅绿⾊区域呈现出规律性的波动。⽽红线右侧部分随着消息量的快速增加通过Broker磁盘存储空间快速上涨得出开始⼀段时间消息保存时间还呈规律性波动但接近最右侧时可以看到消息保存时间的波动频率加快了⽽且消息保存时间快速下降。那么MQ对消息的清理机制到底是什么呢 图1消息保存时间磁盘空间占比趋势图
在介绍清理机制前先来复习⼀下MQ的消息是如何进⾏存储的。 图2commitlog
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服务帮助广大客户更好地使用云、基于云构建更加稳定可靠的业务系统提升业务稳定性。
作者刘维
原文链接
本文为阿里云原创内容未经允许不得转载
