登录
首页 >  数据库 >  Redis

一文详解Redis内存回收的过期策略

来源:51cto

时间:2023-03-14 11:48:58 128浏览 收藏

各位小伙伴们,大家好呀!看看今天我又给各位带来了什么文章?本文标题《一文详解Redis内存回收的过期策略》,很明显是关于数据库的文章哈哈哈,其中内容主要会涉及到Redis、策略、过期等等,如果能帮到你,觉得很不错的话,欢迎各位多多点评和分享!

有一天,产品一哥“林哥”来找我,跟我说:“小李,咱们现在一个需求,商品定时下架的逻辑,这个咱们能做到吗?”,我一想,今年的绩效跟着产品大佬走,当即拍着胸脯说道:“林哥,你就放一百个心,包在我身上~”,然后开始头脑风暴,毕竟要向前(钱)看。

案例

商品定时下架

方案一:消息队列

一文详解Redis内存回收的过期策略

首先我想到当运营童鞋创建(或修改下架时间)商品后,就把该商品放到消息队列中,这样利用 RabbitMQ 的消息 TTL 加死信队列的特性,这个需求搞定,安排上线~

方案二:定时任务+消息队列

过了一段时间,架构师发哥心急火燎的来找我,我一看这阵势这是有大事吧,发哥不等我开口,说:“小李,快看看系统,运营童鞋来找我说,商品到下架时间还能买到;而且运维童鞋反应过节那天咱们的 RabbitMQ 那台服务器内存和硬盘不够用了,尽快处理下”。

我把两件事串联在一起就想到了出问题的点就是“过期自动下架”功能的问题。

第一个问题:商品到下架时间还能买到,我跟运营童鞋确认问题商品,发现很多商品的过期时间是3个月甚至更久,大致猜测可能是延迟时间过长导致了消息延迟失败,查了查默认在使用RabbitMQ的延迟消息功能时候,它的延迟极限是4294967296毫秒,也就是49.7天,很显然现有的功能是无法满足的运营需求,扑街~。

一文详解Redis内存回收的过期策略

第二个问题:过节前夕 RabbitMQ 那台服务器内存和硬盘不够用,我去看运营后台发现创建了大量的新商品,那应该是大量延时下架商品放到消息队列中,以至于产生堆积。

基于以上两点,我做出以下两点改造:

  • 创建(或修改下架时间)商品的时候,不会放到消息队列中,节约资源利用空间;

  • 定时任务每天从商品表中捞取第二天下架的商品放入到消息队列中,缩短延迟时间。

一文详解Redis内存回收的过期策略

搞定~

从这个案例中我借鉴的是 Redis 的内存回收策略,因为 Redis 所有的数据都是存储到内存中的,所以在某些情况下需要对占用的内存进行回收。

Redis 中同时使用了惰性过期和定期过期两种过期策略。

策略一:惰性过期

只有当访问一个 key 时,才会判断该 key 是否已过期,过期则清除。该策略可以最大化地节省 CPU 资源,却对内存非常不友好。极端情况可能出现大量的过期 key 没有再次被访问,从而不会被清除,占用大量内存。

策略二:定期过期

每隔一定的时间,会扫描一定数量的数据库的 expires 字典中一定数量的 key,并清除其中已过期的 key。通过调整定时扫描的时间间隔和每次扫描的限定耗时,可以在不同情况下使得 CPU 和内存资源达到最优的平衡效果。

END

好兄弟可以点赞并关注我的公众号“javaAnswer”,全部都是干货。

一文详解Redis内存回收的过期策略

今天关于《一文详解Redis内存回收的过期策略》的内容介绍就到此结束,如果有什么疑问或者建议,可以在golang学习网公众号下多多回复交流;文中若有不正之处,也希望回复留言以告知!

声明:本文转载于:51cto 如有侵犯,请联系study_golang@163.com删除
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>
评论列表