当前位置:网站首页>Redis 内存满了怎么办?这样置才正确!
Redis 内存满了怎么办?这样置才正确!
2022-08-04 09:04:00 【hebiwen95】
如果过期的数据太多,定时删除无法删除完全(每次删除完过期的 key 还是超过 25%),同时这些 key 再也不会被客户端请求,就无法走惰性删除,内存被打满会怎样?
答案是走内存淘汰机制。
故事从一个叫 Redis 帝国的三公九卿官职说起……
在 Redis 帝国中,整个帝国的国法、家法和军法等都记录在 redis.conf
中,它控制着整个帝国的运行。
公务员占用的国家地盘资源大小限定由名叫「maxmemory」的司法官员制定,一共有两种方式实现:
在运行时使用
CONFIG SET maxmemory 4gb
指定帝国官职人员最大地盘资源为 4GB;将
maxmemory 4gb
法令记录到redis.conf
「法典」中,在帝国运转指定使用该「法典」运行。
需要注意的是,如果 maxmemory
为 0 ,在 64
位「空间」上则没有限制,而 32
位「空间」则有 3GB
的隐式限制。
Redis 内存淘汰策略
*设置了帝国官职地盘资源限制,每年选拔新人就会导致没有地盘资源可以使用怎么办?如何选择一些公务员淘汰?
在 Redis 4.0 时代,一共有 6 种淘汰策略,之后,又新增了 2 种策略。
总体上我们可以根据是否需要淘汰可以分为两大类:
不执行淘汰策略,
noeviction
;根据不同法则淘汰的其他 7 种策略。
noeviction 不退伍策略
默认情况下,资源超过 maxmemory
的值也不会执行淘汰,不允许新人加入。
关系户啊这是,皇亲国戚,永久 vip 啊喂。
随着官职人员的新增,由于不会淘汰,资源容量迟早会满。满了以后,当有「新人」想要进来的时候,Redis 直接返回错误,并罢工。
秀,真是任性。
各式各样的淘汰策略
剩下的 7 种策略还可以根据淘汰的候选集合和淘汰范围分为两大类:
对有设置任职过期时间的职员进行淘汰,没有设定任职过期时间的不会淘汰,淘汰策略如下:
volatile-lru:淘汰最近最少上一线干活的人员;
volatile-lfu:4.0 之后新增的策略,淘汰上一线干活次数最少的人员;
volatile-random:随机淘汰,腾出坑位给新人;
volatile-ttl:淘汰设置了任期时间的公务员,谁最接近任期时间就先淘汰谁。
对所有类型人员淘汰,不管是永久 vip 的皇亲国戚还是设置了任职过期时间的人员。
allkeys-lru:淘汰最近最少上一线干活的职员;
allkeys-lfu:淘汰最少上一线干活的公务员;
allkeys-random:随机淘汰职员,为新兵腾出空位。
故事到这里就结束了,接下来「码哥」分享下在实际 Redis 中如何选择合适的淘汰策略和设置最佳缓存大小给大家。
淘汰执行过程如下图所示:
redis-eviction
客户端发送新命令到服务端;
服务端收到客户端命令,Redis 检查内存使用情况,如果大于
maxmemory
限制,则根据策略驱逐数据。执行新命令。
allkeys-lru 使用场景
假如你的应用存在明显的冷热数据区别,根据经验推荐你使用这个策略,充分利用 LRU 算法把最近最常访问的数据保留,有限的内存提高访问性能。
allkeys-random 使用场景
假如数据没有明显的冷热分别,所有的数据分布查询比较均衡,这些数据都会被随机查询,那就使用 allkeys-random 策略,让其随机选择淘汰数据。
volatile-lru 使用场景
业务场景有一些数据不能删除,比如置顶新闻、视频,这时候我们为这些数据不设置过期时间,这样的话数据就不会被删除,该策略就会去根据 LRU 算法去淘汰那些设置了过期时间且最近最少被访问的数据。
有一个点需要注意下,为 key 执行 expire 设置过期时间会消耗一些内存,所以使用 allkeyds-lru
会提高内存效率。
将需要持数据不能删除的和全都可以淘汰数据的业务系统分别使用不同的 Redis 实例集群是更好的方案。
针对业务场景有一些数据不能删除的使用 volatile-lru
策略,另一类则可以使用 allkyes-lru 或者 allkeys-random
。
Redis 容量设置多大合适
缓存并不是越大越好,用最小的代价去获得最高的收益才是老板想要的。
数据访问有局部性,根据「二八原理」:通常 20% 的数据能支撑 80% 的访问请求。
所以我们可不可以把缓存容量大小设置为总数据量的 20%?
当然,不能这么绝对,这是理想状态。因为可能存在一些个性化需求,不同的用户访问的数据可能差别很大,不完全具备「二八原理」。
我们应当结合实际的访问特点和成本来综合评估。根据经验建议将容量设置成总数据量的 15%~30%。
*码哥,其他淘汰规则比较简单,volatile-lru 和 volatile-lfu 则比较复杂,他们的算法是怎样的?
volatile-lru 使用了 LRU 算法,淘汰最近最少使用的数据。而 volatile-lfu 使用了 LFU 算法,它在 LRU 算法基础上同时考虑了数据的时效性和访问频率,最少访问的 key 会被删除。
至于具体算法细节,我们下回分解。一次性太多的话大家容易在知识的海洋里里呛水。
边栏推荐
- 区分惯性环节与延迟环节
- Four common methods of network attacks and their protection
- GBsae 8c 数据库使用中报错,肿么办?
- MindSpore:【model_zoo】【resnet】尝试用THOR优化器运行时报cannot import name ‘THOR‘
- MindSpore:损失函数问题
- 2022-08-02 Analyze RK817 output 32k clock PMIC_32KOUT_WIFI to WiFi module clock register devm_clk_hw_register
- 下午14:00面试,14:08低着头出来了 ,问的实在是太...
- binder通信实现
- 【正点原子STM32连载】第四章 STM32初体验 摘自【正点原子】MiniPro STM32H750 开发指南_V1.1
- Unity3D 数据加密
猜你喜欢
从零开始的tensorflow小白使用指北
I am 37 this year, and I was rushed by a big factory to...
Cloud function to achieve automatic website check-in configuration details [Web function/Nodejs/cookie]
【正点原子STM32连载】第四章 STM32初体验 摘自【正点原子】MiniPro STM32H750 开发指南_V1.1
MindSpore:mirrorpad算子速度过慢的问题
已解决No module named ‘flask_misaka‘【BUG解决】
[Punctuality Atom STM32 Serial] Chapter 3 Development Environment Construction Excerpted from [Punctual Atom] MiniPro STM32H750 Development Guide_V1.1
After four years of outsourcing, the autumn recruits finally landed
反序列化漏洞
leetcode每天5题-Day06
随机推荐
Producer and Consumer Problems in Concurrent Programming
【高并发基石】多线程、守护线程、线程安全、线程同步、互斥锁
OAK-FFC-4P全网首次测试
No module named 'flask_misaka' has been resolved [BUG solution]
下午14:00面试,14:08低着头出来了 ,问的实在是太...
户外徒步旅行
软件工程国考总结——判断题
字符串与正则表达式(C#)
The separation configuration Libpq is supported, speaking, reading and writing
ansible部署脚本--亲测可用无坑
【论文笔记】Delving into the Estimation Shift of Batch Normalization in a Network
[Punctuality Atom STM32 Serial] Chapter 2 STM32 Introduction Excerpted from [Punctual Atom] MiniPro STM32H750 Development Guide_V1.1
recursive thinking
今日睡眠质量记录71分
Unity3D data encryption
三层交换机/路由器OSPF配置详解【华为eNSP实验】
ZbxTable 2.0 重磅发布!6大主要优化功能!
C# DirectoryInfo类
leetcode每天5题-Day06
It is found that several WRH tables are locked, what should I do?