浅谈专有云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服务，帮助广大客户更好地使用云、基于云构建更加稳定可靠的业务系统，提升业务稳定性。我们期望能够分享更多帮助企业客户上云、用好云，让客户云上业务运行更加稳定可靠的技术，您可用钉钉扫描下方二维码，加入阿里云SRE技术学院钉钉圈子，和更多云上人交流关于云平台的那些事。

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

版权声明：本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。

浅谈专有云MQ存储空间的清理机制相关推荐

浅谈V8引擎中的垃圾回收机制
浅谈V8引擎中的垃圾回收机制这篇文章的所有内容均来自朴灵的<深入浅出Node.js>及A tour of V8:Garbage Collection,后者还有中文翻译版V8 之旅: 垃 ...
多线程之旅之四——浅谈内存模型和用户态同步机制
用户态下有两种同步结构的 volatile construct: 在简单数据类型上原子性的读或者写操作 interlocked construct:在简单数据类型上原子性的读和写操作 (在这里还 ...
浅谈实时对战网络游戏的同步机制
浅谈实时对战网络游戏的同步机制重要的性能指标三种不同方向的技术实现介绍非帧状态同步帧指令同步帧状态同步三种同步方式的对比帧状态同步和ECS架构实时对战游戏,相信大家都不陌生,一些经典的 ...
浅谈Android系统进程间通信（IPC）机制Binder中的Server和Client获得Service Manager接口之路
原文地址: http://blog.csdn.net/luoshengyang/article/details/6627260 在前面一篇文章浅谈Service Manager成为Android进程间 ...
浅谈当前电信检测宽带共享的机制
本人在深圳,家里用的是中国电信的宽带,之前一直带的是两台电脑,后来把笔记本带回家后就出现了各种无法打开网页的问题.究竟是怎么回事? 时间得推回毕业后的那段时间,某一晚,两台台式机还在正常使用的时候.再 ...
java 初始化和清楚_浅谈Java中的初始化和清理
引言这篇文章我们主要介绍Java初始化和清理的相关内容,这些内容虽然比较基础,但是还是在这边做一个简单的总结,方便以后查阅. 初始化过程 Java尽力保证:所有变量在使用之前都会得到恰当的初始化(对 ...
浅谈Chatbot的架构模型和响应机制
不知您是否已注意到:人工智能已经不再是少数科技公司的初级原型产品了.在许多服务类行业中,带有人工智能的聊天机器人(Chatbot)正在逐步取代人工客服,提供及时.周到.互动的服务.通过机器学习的相关技 ...
浅谈JVM的实现与垃圾回收机制
Java被称为是一个人类可读的编程语言,其主要特点是基于类和面向对象,Java的开源版本被称为OpenJDK.Java编程环境由两个部分组成:Java语言和运行环境,运行环境也称为Java虚拟机(JV ...
浅谈Java虚拟机JVM的垃圾回收机制
1. 什么是垃圾要回收垃圾,那么垃圾是什么?简单的逻辑就是不会再被使用的内存对象呗. 2. 怎么判断不再被使用 2.1 引用计数法.统计有多少个引用指向内存对象,如果没有引用指向内存对象,那么该内存 ...

浅谈专有云MQ存储空间的清理机制

浅谈专有云MQ存储空间的清理机制相关推荐

最新文章

热门文章