Redis内存告警?一文吃透Redis过期策略
mhr18 2024-10-25 12:34 18 浏览 0 评论
贾明最近在家做了一次大扫除,收拾出来很多没用的东西,变卖的变卖,送人的送人,扔掉的扔掉。家里宽敞很多。
为什么要给key设置过期时间
内存是非常昂贵的,在Redis中设置key的时候,同时设置key的过期时间,可以确保Redis中的数据不会无限增长,在key过期后由Redis自行删除。节约内存空间。
而且在一些应用场景中,仅仅需要在Redis短时间保存值,如果不设置key的过期时间,则需要我们在程序中自行删除,加重了程序员的心智负担。
如何设置key过期时间
一般情况下,通过使用 Redis 的 EXPIRE 或 PEXPIRE 命令,客户端可以以秒或毫秒的精度设置键(key)的生存时间(Time To Live:TTL)。
其中EXPIRE 命令以秒为单位设置键的生存时间,而 PEXPIRE 命令以毫秒为单位设置键的生存时间。
127.0.0.1:6379> SET key value
OK
127.0.0.1:6379> GET key
"value"
127.0.0.1:6379> EXPIRE key 5
(integer) 1
127.0.0.1:6379> GET key
"value"
127.0.0.1:6379> GET key
(nil)
也可以通过EXPIREAT命令或PEXPIREAT命令设置key的过期时间(expire time)。
其中EXPIREAT命令以秒为单位设置key 的过期时间,PEXPIREAT命令以毫秒设置key的过期时间。
127.0.0.1:6379> SET key value
OK
127.0.0.1:6379> GET key
"value"
127.0.0.1:6379> EXPIREAT key 1700137857
(integer) 1
127.0.0.1:6379> GET key
"value"
127.0.0.1:6379> GET key
(nil)
SETEX命令可以在设置一个字符串键的同时为键设置过期时间,因为这个命令是一个类型限定的命令(只能用于字符串键)
设置key的过期时间有四种方式:
- EXPIRE:设置key的生存时间为ttl秒;EXPIRE < key > < ttl >
- PEXPIRE:设置key的生存时间为ttl毫秒;PEXPIRE < key > < ttl >
- EXPIREAT:设置key的生存时间为timestamp指定的秒数时间戳;EXPIREAT < key > < timestamp >
- PEXPIREAT:设置key的生存时间为timestamp指定的毫秒数时间戳;PEXPIREAT < key > < timestamp >
虽然有多种命令设置key的过期时间,实际上,上面四个命令都是调用expireGenericCommand函数实现的。代码位于expire.c
/* EXPIRE key seconds [ NX | XX | GT | LT] */
void expireCommand(client *c) {
expireGenericCommand(c,mstime(),UNIT_SECONDS);
}
/* EXPIREAT key unix-time-seconds [ NX | XX | GT | LT] */
void expireatCommand(client *c) {
expireGenericCommand(c,0,UNIT_SECONDS);
}
/* PEXPIRE key milliseconds [ NX | XX | GT | LT] */
void pexpireCommand(client *c) {
expireGenericCommand(c,mstime(),UNIT_MILLISECONDS);
}
/* PEXPIREAT key unix-time-milliseconds [ NX | XX | GT | LT] */
void pexpireatCommand(client *c) {
expireGenericCommand(c,0,UNIT_MILLISECONDS);
}
void expireGenericCommand(client *c, long long basetime, int unit) {
robj *key = c->argv[1], *param = c->argv[2];
longlong when; /* unix time in milliseconds when the key will expire. */
longlong current_expire = -1;
int flag = 0;
...
/* EXPIRE allows negative numbers, but we can at least detect an
* overflow by either unit conversion or basetime addition. */
if (unit == UNIT_SECONDS) {
if (when > LLONG_MAX / 1000 || when < LLONG_MIN / 1000) {
addReplyErrorExpireTime(c);
return;
}
when *= 1000;
}
if (when > LLONG_MAX - basetime) {
addReplyErrorExpireTime(c);
return;
}
when += basetime;
...
}
过期时间是怎么保存的
redisDb结构的expires字典保存了数据库中所有键的过期时间,我们称这个字典为过期字典。
过期字典的结构:
- 过期字典的key是一个指针,指向具体的某个key。
- 过期字典的值是个long类型的整数,保存了key对应的过期时间(毫秒级的UNIX时间戳)。
typedefstruct redisDb {
...
dict *expires; /* Timeout of keys with a timeout set */
...
} redisDb;
过期字典案例
上图为带有过期字典的结构,key空间保存了所有的key-value ,过期字典保存了过期时间。
为了展示方便,上图的key空间和过期字典中重复出现了两次alphabet键对象和book键对象。在实际中,key空间的key和过期字典的key都是指针,指向了同一个key对象,所以不会出现任何重复对象,也不会浪费任何空间。
移除过期时间
PERSIST可以用来移除一个key的过期时间。PERSIST < key >
127.0.0.1:6379> set key value
OK
127.0.0.1:6379> expire key 100
(integer) 1
127.0.0.1:6379> ttl key
(integer) 96
127.0.0.1:6379> PERSIST key
(integer) 1
127.0.0.1:6379> ttl key
(integer) -1
计算过期时间
TTL
获取以秒为单位返回键的剩余生存时间
TTL < key >
PTTL
获取以毫秒为单位返回键的剩余生存时间
PTTL < key >
过期判定
- 先判断是否在过期字典中
- 再根据当前的UNIX时间戳是否大于key的过期时间戳
过期策略
到了这里,我们已经知道了key的过期时间都是存在过期字典中的。也知道了该如何去判断key是否已经过期。那么问题来了,如果一个key过期了,什么时候去删除呢?
可能有三种实现方式:
- 定时删除:设置一个key过期时间后,同时创建一个timer定时器。在key过期的时候,由timer处理key的删除。
- 惰性删除:一个key过期后,不进行处理,下次获取的时候,先判断key是否过期,如果过期,则删除。
- 定期删除:每隔一段时间,对key进行扫描一遍,如果过期则删除,至于扫描key的个数和时间间隔可以根据算法决定。
定时删除策略
优点:内存友好,能够及时清理过期key。
缺点:CPU时间不友好,在过期key较多的情况下,删除过期key可能会占用相当一部分CPU时间。尤其在内存不紧张但CPU时间非常紧张的情况下,将CPU时间用于删除与当前任务无关的过期key,无疑会对服务器的响应时间和吞吐量造成影响。
例如,如果正有大量的命令请求在等待服务器处理,并且服务器当前不缺少内存,那么服务器应该优先将CPU时间用在处理客户端的命令请求上面,而不是用在删除过期key上面。
惰性删除策略
优点是对CPU友好,只有在查询的时候,才去判断key是否过期,如果过期就进行删除操作。并且只会操作当前key,对其他key不会进行操作。该策略不会在其他过期key上耗费时间。
但是对内存不好,如果一个key过期了,而又没有进行访问,这个key会一直留在内存中。占用的内容不会得到释放。
试想一下,如果有大量的key过期了,但又没有进行访问,它们一直得不到删除,会一直驻留在内存中,无疑是一笔巨大的负担。
定期删除策略
定期删除可以说是定时删除和惰性删除的中和,每隔一段时间,扫描一下,进行过期key删除操作。可以通过限制执行频率和执行时间来,来避免占用过多的CPU。
过期策略 | 优点 | 缺点 |
定时删除 | 内存友好 | 占用CPU时间,可能影响响应时间和吞吐量 |
惰性删除 | 存在内存泄漏风险 | CPU友好 |
定期删除 | 定时删除和惰性删除的中和 | 执行频繁/执行时间太长,退化成定时删除,反之退化成惰性删除 |
实际上,Redis采用的是惰性删除和定期删除两种策略。通过配合使用这两种删除策略,服务器可以很好地在合理使用CPU时间和避免浪费内存空间之间取得平衡
删除策略的实现
本节我们来看下Redis中两种删除策略的代码实现。
惰性删除实现
- 当客户端执行读写操作时,Redis 在检索key之前会检查其过期时间。如果key已过期,则 Redis 返回一个表示key不存在的响应,并在需要时进行惰性删除。
- 惰性删除是指在读取或写入key之前,Redis 会检查该键是否过期。如果过期,则立即删除该key。
定期删除实现
- Redis 使用一个定时器来周期性地执行定期删除操作,以清理过期key。
- 定期删除是通过遍历数据库中的过期key来进行的。
- 在每个定期删除周期内,Redis 随机选择一部分过期键进行处理。
- 对于被选中的过期key,Redis 遍历它们,并检查每个key的过期时间。如果某个key已经过期,则将其删除并释放相关的内存空间
- 在处理过期键时,Redis 记录已删除的键数量,并在超过阈值后停止遍历,以避免长时间的阻塞操作。
AOF、RDB、复制的影响
AOF
AOF写入
Redis开启AOF后,如果某个key过期,如果这个时候还没执行惰性删除或者定期删除,那么AOF文件不会产生变化。当惰性删除或者定期删除执行过之后,会向AOF文件中显示写入一条DEL命令。
比如访问过期的key1会经历下面的流程(惰性删除为例):
- 删除key1
- 向AOF文件追加DEL key1命令
- 向客户端返回空
AOF重写
AOF重写的时候,会对key进行检查,如果发现key已经过期,不会重写到AOF文件中。和下文的RDB加载很类似。
RDB
生成RDB
在调用BGSAVE命令或者SAVE命令新生成RDB文件的时候,Redis会检查key是否过期,如果key已经过期,则不会写入RDB文件中。
比如假设Redis中有三个key,key1,key2,key3。其中key2已经过期,那么写入RDB的时候,会把key2忽略,将key1和key3写入RDB文件中。
加载RDB
Redis启动的时候,如果开了RDB模式,将会在启动过程中加载RDB文件。
- 如果是在主节点上运行,Redis会对key进行检查,未过期的key加载到Redis中,过期key则忽略。
- 如果是在从节点上运行,Redis不会对key进行检查,无论key是否过期,都会加载到Redis中。
复制
在复制模式下,过期key的删除由主节点进行操作,从节点不进行处理。
- 主节点在删除一条key后,会向所有的从节点发送一条DEL命令。
- 从节点在执行读命令的时候,遇见过期key不会进行删除操作。
- 从节点接收到主节点发来的DEL命令,执行删除key操作。
这么做是为了保证主从一致性。删除的操作统一由主节点执行,避免了从节点上已经删除但是主节点还存在的情况。
相关推荐
- Redis合集-使用benchmark性能测试
-
采用开源Redis的redis-benchmark工具进行压测,它是Redis官方的性能测试工具,可以有效地测试Redis服务的性能。本次测试使用Redis官方最新的代码进行编译,详情请参见Redis...
- Java简历总被已读不回?面试挂到怀疑人生?这几点你可能真没做好
-
最近看了几十份简历,发现大部分人不是技术差,而是不会“卖自己”——一、简历死穴:你写的不是经验,是岗位说明书!反面教材:ד使用SpringBoot开发项目”ד负责用户模块功能实现”救命写法:...
- redission YYDS(redission官网)
-
每天分享一个架构知识Redission是一个基于Redis的分布式Java锁框架,它提供了各种锁实现,包括可重入锁、公平锁、读写锁等。使用Redission可以方便地实现分布式锁。red...
- 从数据库行锁到分布式事务:电商库存防超卖的九重劫难与破局之道
-
2023年6月18日我们维护的电商平台在零点刚过3秒就遭遇了严重事故。监控大屏显示某爆款手机SKU_IPHONE13_PRO_MAX在库存仅剩500台时,订单系统却产生了1200笔有效订单。事故复盘发...
- SpringBoot系列——实战11:接口幂等性的形而上思...
-
欢迎关注、点赞、收藏。幂等性不仅是一种技术需求,更是数字文明对确定性追求的体现。在充满不确定性的网络世界中,它为我们建立起可依赖的存在秩序,这或许正是技术哲学最深刻的价值所在。幂等性的本质困境在支付系...
- 如何优化系统架构设计缓解流量压力提升并发性能?Java实战分享
-
如何优化系统架构设计缓解流量压力提升并发性能?Java实战分享在高流量场景下。首先,我需要回忆一下常见的优化策略,比如负载均衡、缓存、数据库优化、微服务拆分这些。不过,可能还需要考虑用户的具体情况,比...
- Java面试题: 项目开发中的有哪些成长?该如何回答
-
在Java面试中,当被问到“项目中的成长点”时,面试官不仅想了解你的技术能力,更希望看到你的问题解决能力、学习迭代意识以及对项目的深度思考。以下是回答的策略和示例,帮助你清晰、有说服力地展示成长点:一...
- 互联网大厂后端必看!Spring Boot 如何实现高并发抢券逻辑?
-
你有没有遇到过这样的情况?在电商大促时,系统上线了抢券活动,结果活动刚一开始,服务器就不堪重负,出现超卖、系统崩溃等问题。又或者用户疯狂点击抢券按钮,最后却被告知无券可抢,体验极差。作为互联网大厂的后...
- 每日一题 |10W QPS高并发限流方案设计(含真实代码)
-
面试场景还原面试官:“如果系统要承载10WQPS的高并发流量,你会如何设计限流方案?”你:“(稳住,我要从限流算法到分布式架构全盘分析)…”一、为什么需要限流?核心矛盾:系统资源(CPU/内存/数据...
- Java面试题:服务雪崩如何解决?90%人栽了
-
服务雪崩是指微服务架构中,由于某个服务出现故障,导致故障在服务之间不断传递和扩散,最终造成整个系统崩溃的现象。以下是一些解决服务雪崩问题的常见方法:限流限制请求速率:通过限流算法(如令牌桶算法、漏桶算...
- 面试题官:高并发经验有吗,并发量多少,如何回复?
-
一、有实际高并发经验(建议结构)直接量化"在XX项目中,系统日活用户约XX万,核心接口峰值QPS达到XX,TPS处理能力为XX/秒。通过压力测试验证过XX并发线程下的稳定性。"技术方案...
- 瞬时流量高并发“保命指南”:这样做系统稳如泰山,老板跪求加薪
-
“系统崩了,用户骂了,年终奖飞了!”——这是多少程序员在瞬时大流量下的真实噩梦?双11秒杀、春运抢票、直播带货……每秒百万请求的冲击,你的代码扛得住吗?2025年了,为什么你的系统一遇高并发就“躺平”...
- 其实很多Java工程师不是能力不够,是没找到展示自己的正确姿势。
-
其实很多Java工程师不是能力不够,是没找到展示自己的正确姿势。比如上周有个小伙伴找我,五年经验但简历全是'参与系统设计''优化接口性能'这种空话。我就问他:你做的秒杀...
- PHP技能评测(php等级考试)
-
公司出了一些自我评测的PHP题目,现将题目和答案记录于此,以方便记忆。1.魔术函数有哪些,分别在什么时候调用?__construct(),类的构造函数__destruct(),类的析构函数__cal...
- 你的简历在HR眼里是青铜还是王者?
-
你的简历在HR眼里是青铜还是王者?兄弟,简历投了100份没反应?面试总在第三轮被刷?别急着怀疑人生,你可能只是踩了这些"隐形求职雷"。帮3630+程序员改简历+面试指导和处理空窗期时间...
你 发表评论:
欢迎- 一周热门
- 最近发表
- 标签列表
-
- oracle位图索引 (63)
- oracle批量插入数据 (62)
- oracle事务隔离级别 (53)
- oracle 空为0 (50)
- oracle主从同步 (55)
- oracle 乐观锁 (51)
- redis 命令 (78)
- php redis (88)
- redis 存储 (66)
- redis 锁 (69)
- 启动 redis (66)
- redis 时间 (56)
- redis 删除 (67)
- redis内存 (57)
- redis并发 (52)
- redis 主从 (69)
- redis 订阅 (51)
- redis 登录 (54)
- redis 面试 (58)
- 阿里 redis (59)
- redis 搭建 (53)
- redis的缓存 (55)
- lua redis (58)
- redis 连接池 (61)
- redis 限流 (51)