关于Redis中RDB持久化方式之save配置自动触发的进一步深究

文章讲述了作者在调试RedisRDB持久化时对save配置的误解,以为60秒内必须达到100次key更新才会触发持久化,实际上save配置是每60秒检查key更新次数是否累积达到阈值。
摘要由CSDN通过智能技术生成

引言

save 60 100 这个配置的意思是 “60秒内若Redis中至少有100个key更新则触发RDB持久化” 吗?

注明

写此文章是记录关于在调试RDB持久化中save配置与预期效果不一致引起的一些疑惑,结构就是:从产生疑惑到如何解决疑惑。

OK,let’s go

起因

最近想测试下Redis的RDB持久化机制,同时借助jmeter来做压测,于是乎打算从save配置开始入手。

鉴于本人笔记本性能中庸,所以我打算先从简单的并发数开始进行压测,于是就把RDB的save配置设置为了save 60 100。按照我的理解就是:“60秒内若Redis中至少有100个key更新则触发RDB持久化”,这样子看起来也好像没什么毛病。

于是我就开始进行实测了,但是,我的实测并不是简简单单真的给Redis在60秒内set至少100个key,因为这是必然结果,肯定会持久化生成dump.rdb文件的。

本文我对Redis做更新key操作,都是用set方式。

我想试的是,“在60秒内set小于100个key”,为什么这样子搞呢?因为既然是60秒内set至少100个key才会生成dump.rdb,那反之就是不生成了吧。那是不是只要我卡着这一点,每隔60秒内只要set不超过100个就不会进行持久化了呗?(这种想法有点奇怪,但就是想试试

于是开始第一次实验,以下是我Redis-5.0.12的save配置以及jmeter的配置:
在这里插入图片描述
为了看到是否有进行RDB操作,我把Redis日志输出到redis.log文件
在这里插入图片描述

jmeter的过程仅是调用了服务器的一个api接口去set Redis的值,没有多余的操作了。Ramp-Up时间设置2秒也只是给我笔记本的cpu缓口气而已。
在这里插入图片描述

启动成功,这里都是一些基本的日志信息
在这里插入图片描述

然后,我用jmeter第一次发送95个请求到服务器(相当于在Redis中set 95个key),全部发送成功,此时redis.log这个日志还没有任何动静,这点不用解释,因为压根儿就没达到save配置触发的条件。
在这里插入图片描述

然后,我发送完毕后,我直接等待5分钟,做的就是为了等待超过60秒。
此时去喝杯水。。

五分钟够了,回来接着发送第二次95个请求,也都是全部成功发送了。在这里插入图片描述

产生疑惑

但 结果却是。。不看不知道,一看吓一跳,此时redis.log居然显示我达到了save的条件!然后给我进行RDB持久化了!
在这里插入图片描述
此时,我都迷了,咦??不是说好的save 60 100 60秒内若Redis中更新至少有100个key则触发RDB持久化 吗?明明我才set了95个而已啊,怎么给我持久化了。

于是我反复阅读redis.conf配置文件在save配置那块的注释说明,例如下图红框的内容就是说:
“900秒(15分钟)后,如果至少有1个key发送改变”
“300秒(5分钟)后,如果至少有10个key发送改变”
“60秒(1分钟)后,如果至少有10000个key发送改变”
在这里插入图片描述

我乍一看,这说的也没有毛病呀!咱也知道Redis有个时间窗口的概念,就拿save 60 100来说,60秒就算是一个时间窗口,就是每隔60秒会检查一次是否达到100个key改变,每隔60秒检查一次…如此类推。

我的配置save 60 100,虽然时间窗口肯定是一直循环60秒等待的,但我的100没有达成条件呀?于是我带着这个疑问,到处寻找资料,解答,可惜的是,答案几乎都是那句话 “seconds秒内若Redis中至少有changes个key更新则触发RDB持久化

后续则是无限的寻找解决困惑的相关文章以及各种资料。。

看到曙光

直到有一天,我看到一个讲解Redis RDB相关的视频,关键是视频中的一条弹幕点明了我。
那个弹幕说:“不是seconds秒内操作changes次,是每seconds秒检查够不够changes次”。
结合我的save 60 100的意思即:“不是60秒内操作100次,是每60秒够不够100次”。突然我灵光一闪,这说的有道理呀,我第一次操作虽然在60秒内set了95条数据,但即使我隔了五分钟(期间经历了差不多5次的60秒时间窗口)再去set 95 条数据,也还是会进行RDB持久化的。因为前后两次累计95+95=190,已经完完全全大于我当初设定的100次了,所以才会进行RDB持久化,这样符合我实操的结果了。

所以我现在才明白我的疑惑,是我理解错了,针对于save 60 100错误的理解是:60秒内,必须要达到100次操作才进行RDB持久化,而且每次的60秒都是要重新计算key更新的数量,即归零。这样的理解是错误的。

后面我理解后才明白,实际上save配置的changes是脱离在时间窗口外的,会自己累计的,而并非每一次60秒都会归零。按照前面错误的理解,假如在业务场景,save的配置如save 60 10000,若每次的60秒时间窗口内我set的key达不到10000,那岂不是永远都无法进行RDB?内存不得一堆坨坨的数据,而且还要时刻谨防Redis服务器挂掉,数据全没了。。

收工

我的疑惑因此也得到了解决,感谢弹幕那位兄弟一句话点明了我!!

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值