当前位置:网站首页>Redis内存回收
Redis内存回收
2022-07-28 02:37:00 【三月不灭】
Redis内存回收
Redis之所以性能强,最主要的原因就是基于内存存储。然而单节点的Redis其内存大小不宜过大,会影响持久化或主从同步性能。
我们可以通过修改配置文件来设置Redis的最大内存:

当内存使用达到上限时,就无法存储更多数据了,所以需要对key进行清理。
过期删除策略
通过expire命令给Redis的key设置TTL(存活时间),当key的TTL到期以后,再次访问name返回的是nil,说明这个key已经不存在了,对应的内存也得到释放,从而起到内存回收的目的。
Redis本身是一个典型的key-value内存存储数据库,因此所有的key、value都保存在Dict结构中
不过在其database结构体中,有两个Dict:一个用来记录key-value;另一个用来记录key-TTL。
![[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-bddLu8bJ-1658577054237)(network-img/image-20220723145235610.png)]](/img/2c/29df4008dc2df98ecd61f2a5d20162.png)
![[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-bvbYDFYl-1658577054238)(network-img/image-20220723145403305.png)]](/img/f6/b7f70b1eee1bd328272aea0ed6b0be.png)
这里有两个问题需要我们思考:
Redis是如何知道一个key是否过期呢?
- 利用两个Dict分别记录key-value对及key-ttl对
是不是TTL到期就立即删除了呢?
要实现立即删除必须监视每个key,每个key都设置了一个定时器,在key很多时,都设置一个定时器会给CPU造成很大的压力
常用过期删除策略:惰性删除、周期删除
过期策略-惰性删除
惰性删除:并不是在TTL到期后就立刻删除,而是在访问一个key的时候,检查该key的存活时间,如果已经过期才执行删除
![[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-gFO2Fjv3-1658577054238)(network-img/image-20220723180857717.png)]](/img/0e/c13ebd46cd050c0c5514fe88f3e902.png)
上图中只有检查完key没问题,才能读和写。但是因为惰性删除只有在访问的时候才检查有没有过期,假如某个key很长时间都没有访问,那这个key不会被删除,当被没有访问的key过多时,就会有大量垃圾数据
周期删除
周期删除:顾明思议是通过一个定时任务,周期性的抽样部分过期的key,然后执行删除。执行周期有两种;
- Redis会设置一个定时任务serverCron(),按照server.hz的频率来执行过期key清理,模式为SLOW
- Redis的每个事件循环前会调用beforeSleep()函数,执行过期key清理,模式为FAST

SLOW模式规则:
- 执行频率受server.hz影响,默认为10,即每秒执行10次,每个执行周期100ms。
- 执行清理耗时不超过一次执行周期的25%。
- 逐个遍历db中的bucket,抽取20个key判断是否过期。
- 如果没达到时间上限(25ms)并且过期key比例大于10%,再进行一次抽样,否则结束
**FAST模式规则(**过期key比例小于10%不执行)∶
- 执行频率受beforesleep()调用频率影响,但两次FAST模式间隔不低于2ms
- 执行清理耗时不超过1ms
- 逐个遍历db中的bucket,抽取20个key判断是否过期
- 如果没达到时间上限(1ms)并且过期key比例大于10%,再进行一次抽样,否则结束
FaST清理速度非常快,而SLOW执行效率低,SlOW属于低频长时间的清理,适合清理大量key,而fast属于高频清理少量key
淘汰策略
在大型项目,当数据量非常大,只淘汰过期的key也难以满足内存的使用
内存淘汰︰redis在任何命令执行前都会检查内存是否溢出,当Redis内存使用达到设置的阈值时,Redis主动挑选部分key删除以释放更多内存。Redis会在处理客户端命令的方法processCommand()中尝试做内存淘汰:

Redis支持8种不同策略来选择要删除的key:(可在配置文件中设置淘汰策略)
- noeviction:不淘汰任何key,但是内存满时不允许写入新数据,默认就是这种策略。
- volatile-ttl:对设置了TTL的key,比较key的剩余TTL值,TTL越小越先被淘汰
- allkeys-random:对全体key,随机进行淘汰。也就是直接从db->dict中随机挑选
- volatile-random:对设置了TTL的key,随机进行淘汰。也就是从db->expires中随机挑选。
- allkeys-lru:对全体key,基于LRU算法进行淘汰
- volatile-lru:对设置了TTL的key,基于LRU算法进行淘汰
- allkeys-lfu:对全体key,基于LFU算法进行淘汰
- volatile-lfu:对设置了TTL的key,基于LFI算法进行淘汰
比较容易混淆的有两个:
- LRU(Least Recently Used),最少最近使用。用当前时间减去最后一次访问时间,这个值越大则淘汰优先级越高。
- LFU (Least Frequently Used),最少频率使用。会统计每个key的访问频率,值越小淘汰优先级越高。
Redis的数据都会被封装为Redisobject结构:
![[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-AP5h2ZQQ-1658577054239)(network-img/image-20220723183816245.png)]](/img/3e/b98098ebdafde30d467c87b2ce691e.png)
LFU的访问次数叫做逻辑访问次数(因为一个key访问的次数很多,低8位记录访问次数,8位不够,所以使用了一个算法计算逻辑访问次数,记录是一个概率性次数),所以并不是每次key被访问都计数,而是通过运算:
1)生成0~1之间的随机数R
2)计算1/(旧次数*lfu_log_factor + 1),记录为P,lfu_log_factor默认为10
3)如果R<P,则计数器+1,且最大不超过255
4)访问次数会随时间衰减,距离上一次访问时间每隔lfu_decay_time分钟(默认1),计数器-1(高16位记录最后一次访问时间,所以可以得到距离上一次访问时间间隔
淘汰策略执行流程图:
![[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-4iGOq9s3-1658577054239)(network-img/image-20220702223159351.png)]](/img/ec/38caed1d7e08983f7c36d242a730cc.png)
首先会判断一下这个内存是否充足,即当前已经使用的内存有没有达到内存最大值
充足,则退出;否则,就尝试进行驱逐。驱逐前判断如果策略是NO_EVICTION,则直接结束。不是,则需要驱逐:不管是哪种淘汰,都会判断是从所有key中驱逐还是设置了TTL的键中判断,判断完后判断是哪种策略(随机,LRU,LFU,TTL):
1)如果是随机模式,那就接从库里随便挑一个删了,删完了以后判断是否内存是否足够,不够继续判断删除,够了则终止。
2)如果是LRU|LFU|TTL,这三种有个共同的特点要去得到LLU,LFU,TTL值做比较(redis中有大量的key,不可能一个个计算比较删除,redis采用的不是严格的LRU,而是使用一个池子eviction_pool,一个淘汰池,池子一开始是空的,现在要选一些key淘汰,可又不想去遍历所有的key,可以从数据库中挑一些样本,放到池子里,比较池子里的key谁需要淘汰。虽然这种准确率不足把所有的key都遍历一遍,不过它的准确率还是可以接受的,而且这种方式性能比较好),挑选样本时,首先会去redis中一个数据库,挑选maxmemory_samples(默认5)数量的key。
如何挑选,不同策略挑选方式不一样。
如果说不同策略有不同标准,在放到池子中时标准也不一样,不同策略就歹写一种判断逻辑,不方便统一,为了解决这个问题,就指定了这个池子的淘汰标准(会按照key中某一个值升序排列,排列完后值越大的优先淘汰)那按什么排序,不同策略不一样
LRU:now-LRU(因为LRU越小越淘汰,但是标准是升序淘汰,所以用now-LRU,即没有被访问的空闲时间)
LFU:频率,用LFU最大值255-LFU
TTL:最大时间减去maxTTL
样本选出来要判断池子满了,没满直接放池子,满了需要比较样本的最大值和池子中最小的值哪个更小,样本最大值更小就不应该淘汰。
一个数据库处理完了,循环继续处理下一个DB,若数据库处理完,把值大的淘汰。
总结:redis可以设置内存上限,为了避免内存达到上限,有两种策略,一个是内存过期(惰性删除,周期删除),另一个是内存淘汰,
参考:https://www.bilibili.com/video/BV1cr4y1671t?p=146&vd_source=4b2762d41a0675aa9823e3c6194fb61d
边栏推荐
- Design of the multi live architecture in different places of the king glory mall
- 【下载文件】uniapp开发小程序,下载文件并保存到本地
- The applet has obtained the total records and user locations in the database collection. How to use aggregate.geonear to arrange the longitude and latitude from near to far?
- 【红队】ATT&CK - 文件隐藏
- 【AcWing 327. 玉米田】状压dp
- CSDN Top1 "how does a Virgo procedural ape" become a blogger with millions of fans through writing?
- 行业洞察 | 语音识别真的超过人耳朵了吗?
- 数据湖:海量日志采集引擎Flume
- QFileDevice、QFile、QSaveFile、QTemporaryFile
- 4、 Analysis of solid state disk storage technology (paper)
猜你喜欢

Full of dry goods, hurry in!!! Easy to master functions in C language

Design of the multi live architecture in different places of the king glory mall

MySQL index learning

工程电磁场复习基本知识点

Distributed transaction Senta (I)
![[stream] basic knowledge of stream](/img/33/0bd85f7e029c81d0c20f463ebb972a.png)
[stream] basic knowledge of stream

综合 案例

GAMES101复习:光线追踪(Ray Tracing)

基于c8t6芯片开发RC522模块实现呼吸灯
[email protected] Annotation usage"/>[email protected] Annotation usage
随机推荐
vba批量读取sql的create文来创建表
酒店vr全景展示拍摄提供更多合作和洽谈的机会
Kubernetes -- Introduction
CAD创建组却没有组合在一起?
《MySQL数据库进阶实战》读后感(SQL 小虚竹)
vscode debug显示多列数据
[acnoi2022] one step short
C#WinForm开发:如何将图片添加到项目资源文件(Resources)中
“讳疾忌医”的开源走不远
My approval & signature function of conference OA project
[email protected] Annotation usage
[stream] parallel stream and sequential stream
[email protected]注解使用
嵌入式开发:提示和技巧——用C进行防御性编程的最佳实践
Alibaba cloud international email service package purchase process
注意,这些地区不能参加7月NPDP考试
Blue Bridge Cup: the ninth - "lantern controller"
ELS keyboard information
QFileDevice、QFile、QSaveFile、QTemporaryFile
JVM memory layout detailed, illustrated, well written!