浅谈专有云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服务,帮助广大客户更好地使用云、基于云构建更加稳定可靠的业务系统,提升业务稳定性。
作者:刘维
本文为阿里云原创内容,未经允许不得转载
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
Google 发布 leaky.page 演示浏览器中的 Spectre 漏洞
近日,Google 安全团队公布了其关于在浏览器的 JavaScript 引擎中利用 Spectre 漏洞的概念验证代码(PoC),并于 leaky.page 网站上公开了一个交互式攻击演示。 Spectre 漏洞是一个存在于分支预测实现中的硬件缺陷及安全漏洞,含有预测执行功能的现代微处理器均受其影响,漏洞原理是利用基于时间的旁路攻击,允许恶意进程获得其他程序在映射内存中的数据内容。基于其攻击行为类型,赋予了两个通用漏洞披露 ID,分别是 CVE-2017-5753(bounds check bypass,边界检查绕过)和 CVE-2017-5715(branch target injection,分支目标注入),于 2018 年 1 月随同另一个也基于推测运行机制的、属于重量级信息安全漏洞的硬件缺陷 “Meltdown”(熔毁)一同公布。 根据 Google 的 Leaky.Page 演示,当在 Intel SkylakeCPU(i7-6500U)上运行 Chrome 88 时,它有可能以 1kB/s 的速度泄露数据。该概念验证代码是针对 Intel Skylake CPU 的,而对...
- 下一篇
不重复造轮子都是骗小孩的,教你手撸 SpringBoot 脚手架!
持续坚持原创输出,点击蓝字关注我吧 作者:小傅哥博客:https://bugstack.cn ❝ 沉淀、分享、成长,让自己和他人都能有所收获!😜 ❞ 目录 一、前言 二、什么是脚手架呢? 三、谁提供了脚手架? 1、Spring 官网脚手架 2、阿里云脚手架 四、手撸一个脚手架! 1. 工程框架 2. 应用层定义生成类接口 3. FTL 模板定义 4. FTL 生成文件 5. 创建框架入口 6. 测试验证 五、源码下载 六、总结 七、系列推荐 一、前言 为什么我们要去造轮子? 造轮子的核心目的,是为了解决通用共性问题的凝练和复用。 虽然市面上已经有了大量成熟稳定用于支撑系统建设的轮子,也就是服务、框架、组件、工具等,但对于一些较大型的公司来说,这些轮子可能并不一定能很好的支撑起系统需要承载的服务体量,这个时候就需要自建一些轮子。 而提倡的不重复造轮子,新造轮子不一定能保证稳定性。一般用在以官网推出的核心轮子上是适合的,比如 SpringBoot、Netty、HBase 等。但对于一些特殊场景的解决方案工具型组件,通常是没有完全符合的轮子的,就像 SpringBoot 脚手架。 其实每个...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
-
Docker使用Oracle官方镜像安装(12C,18C,19C)
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- CentOS8编译安装MySQL8.0.19
- Docker快速安装Oracle11G,搭建oracle11g学习环境
- SpringBoot2配置默认Tomcat设置,开启更多高级功能
- MySQL8.0.19开启GTID主从同步CentOS8
- CentOS7,8上快速安装Gitea,搭建Git服务器
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果
推荐阅读
最新文章
- CentOS8编译安装MySQL8.0.19
- SpringBoot2整合Thymeleaf,官方推荐html解决方案
- 设置Eclipse缩进为4个空格,增强代码规范
- CentOS7,8上快速安装Gitea,搭建Git服务器
- Windows10,CentOS7,CentOS8安装MongoDB4.0.16
- CentOS7安装Docker,走上虚拟化容器引擎之路
- CentOS6,7,8上安装Nginx,支持https2.0的开启
- SpringBoot2全家桶,快速入门学习开发网站教程
- CentOS7编译安装Cmake3.16.3,解决mysql等软件编译问题
- Docker安装Oracle12C,快速搭建Oracle学习环境