关于前端:浅谈专有云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 服务，帮忙广大客户更好地应用云、基于云构建更加稳固牢靠的业务零碎，晋升业务稳定性。

作者：刘维
原文链接
本文为阿里云原创内容，未经容许不得转载