点赞多大胆,就有多大产!开源促使进步,献给每一位技术使用者和爱好者!
干货满满,摆好姿势,点赞发车
Redis数据淘汰策略
前言
Redis作为一个内存数据库,性能十分高,主要依赖的硬件资源就是内存,据官方数据表示Redis读的速度是110000次/s,写的速度是81000次/s,我们向Redis中源源不断存储数据,内存空间有限,这时淘汰无用数据释放空间,存储新数据就变得尤为重要,Redis提供了数据淘汰策略来释放内存
内容偏向理论,需要大家发挥想象脑补画面
,最好记下来,成为面试时的谈资
内存配置
Redis在生产环境中,采用配置参数maxmemory
的方式来限制内存大小。当实际存储内存超出maxmemory 参数值时,可以通过Redis内存淘汰策略,来决定如何腾出新空间继续支持读写工作
上图是Redis5.0.5版本的配置,默认是被注释掉关闭的,单位是字节,当设置为0时没有限制
淘汰策略
Redis4之后为我们提供了八个不同的内存置换策略。之前版本提供了6种
- volatile-lru:从已设置过期时间的数据集(server.db[i].expires)中挑选最近最少使用的数据淘汰。没有设置过期时间的key不会被淘汰,这样就可以在增加内存空间的同时保证需要持久化的数据不会丢失
- volatile-ttl:从已设置过期时间的数据集(server.db[i].expires)中挑选将要过期的数据淘汰。
- volatile-random:从已设置过期时间的数据集(server.db[i].expires)中任意选择数据淘汰。
volatile-lfu
:从已设置过期时间的数据集(server.db[i].expires)挑选使用频率最低的数据淘汰。- allkeys-lru:从数据集(server.db[i].dict)中挑选最近最少使用的数据淘汰
allkeys-lfu
:从数据集(server.db[i].dict)中挑选使用频率最低的数据淘汰。- allkeys-random:从数据集(server.db[i].dict)中任意选择数据淘汰
- no-enviction(驱逐):禁止驱逐数据,这也是默认策略。意思是当内存不足以容纳新入数据时,新写入操作就会报错,请求可以继续进行,线上任务也不能持续进行,采用no-enviction策略可以保证数据不被丢失。
这八种大体上可以分为4中,lru、lfu、random、ttl,其中lfu
方式是新增策略,也就是根据使用率来淘汰数据
通过设置
maxmemory-policy
设置淘汰策略
Redis是怎么触发淘汰机制的呢
首先,客户端存储数据,肯定需要有内存来存储
其次,Redis检查内存使用情况,如果实际使用内存已经超出maxmemory
,Redis就会根据用户配置的淘汰策略选出无用的key
最后,确认选中数据没有问题,成功执行淘汰任务
过期键删除策略
我们都知道Redis中的key是可以设置过期时间的,这里提一下怎么判定过期键
-
Redis键的过期时间都保存在过期字典中
-
检查给定键是否存在于字典中,如果有取得键的过期时间
-
检查当前UNIX时间戳是否大于键的过期时间,如果是的话那么该键已经过期,否则键未过期
接下来我们就说说过期的key如何被无情抛弃的
定时删除
-
在设置键的过期时间的同时,创建一个定时器(timer),让定时器在键的过期时间来临时,立即执行对键的删除操作;
-
定时删除操作对于内存来说是友好的,通过使用定时器,可以保证尽快的将过期键删除,释放所占内存
-
对于CPU来说不是友好的,如果过期键比较多的话,删除过期键这一行为可能占用相当一部分CPU时间,在内存不紧张但是CPU紧张的情况下,将CPU时间用在删除和当前任务无关的过期键上,无疑会对服务器的响应时间和吞吐量造成影响,在某些情况下有点分不清主次啦!
-
例如:如果有大量的命令请求等待服务器处理,并且服务器当前不缺少内存,那么服务器应该优先将CPU时间用在处理客户端的请求上,而不是删除过期键上面
-
创建一个定时器需要用到Redis服务器中的事件事件,当前时间事件的实现方式是
无序链表
,查找一个事件的时间复杂度为O(N),并不能高效处理大量时间事件 -
因此要让服务器创建大量的定时器,从而实现定时策略删除,在这里是不现实的
惰性删除
-
对CPU是友好的,程序只会在取出键时才对键进行过期检查,这可以保证删除过期键的操作只会在非做不可时进行,并且删除的目标仅限于当前处理的键,这个策略不会在删除其他无关的过期建上浪费任何CPU时间
-
对内存是不友好的,如果一个键已经过期,而这个键仍然保留在数据库中,那么只要这个过期键不被删除,它所占的内存就不会释放
-
在使用惰性删除策略时,如果数据库中有非常多的过期键,而这些过期建又恰好没有被访问到的话,那么它们也许永远也不会被删除(除非用户手动执行FLUSHDB或者FLUSHALL,谨慎别用,企业中一般会将这连个命令禁用甚至删除掉,劲太猛了),这种情况是不是就是我们程序中说的
内存泄漏
,无用的数据占用大量内存,对于Redis这种内存数据库来说肯定不是好事 -
例如:对于一些和时间有关的数据,比如日志(log),在某个时间点之后,对它们的访问就会减少,甚至不再访问,如果这类过期数据大量的积压在数据库中,用户以为服务器已经将它们删除了,但实际还存在,而且键所占内存也没有释放,会造成很严重的后果
定期删除
- 上边两种删除策略在单一使用时都有明显的缺陷,定时删除占用太多CU时间,降低服务器吞吐量和响应时间,惰性删除浪费太多内存,有内存泄漏危险,
定期删除
就是前两种策略的整合和折中方案 - 定期删除策略每隔一段时间执行一次删除过期键操作,并通过限制删除操作执行的时长和频率来减少删除操作对CPU时间的影响
- 通过定期删除过期键,定期删除策略有效地减少因过期键带来的内存浪费
定期删除策略的难点在于确定删除操作的时长和频率
- 如果删除处操作执行的太频繁,或者执行的时间太长(时间长不一定好),定时删除策略不就退化成定时删除策略了嘛,以至于CPU将过多的时间耗费在删除粗过期键上
- 如果删除处理执行的太少,或者时间太短~~~,定期删除策略又会向惰性删除那样,出现内存浪费情况
- 因此采用定期删除策略,服务器必须根据情况,设置删除操作的执行时长和执行频率
Redis服务器实际使用的删除策略是惰性删除和定时删除两种,相互配合可以在CPU使用时间和内存空间取得平衡,这里我们先说一下概念,具体实现待我阅读源码再与大家分享
AOF、RDB和复制功能对过期键处理
RDB
生成RDB文件
执行SAVE
或者BGSAVE
创建新的RDB文件时,程序会对数据库中的键进行检查,已过期的键不会被保存到新创建的RDB文件中,因此数据库包含过期键不会对新的RDB文件造成影响
载入RDB文件
在启动Redis服务器时,如果服务器开启了RDB文件,那么服务器就会对RDB文件进行载入
- 如果当前服务器是
Master
,程序会对文件中保存的key进行检查,未过期的键会被载入到数据库中,而过期的键则会被忽略,所以过期键对载入RDB文件的主服务器不会造成影响 - 如果当前服务器是
Slave
,文件中保存的所有键,无论是否过期,都会被载入到数据库中,不过,因为主从服务器在进行数据同步时,从服务器的数据库就会被同步成和主服务器一致,所以一般来讲,过期键对载入RDB文件的从服务器也不会造成影响 - 例如:数据库中有k1, k2, k3三个键,k2已经过期,启动服务时
- 如果是主服务器,k1, k3会被载入,k2会被忽略
- 如果是从服务器,k1, k2, k3都会被载入
AOF
AOF文件写入
当服务器以AOF持久化模式运行时,如果数据库中的某个key已经过期,但是他还没有被惰性删除或者定期删除,那么AOF文件不会因为这个过期键产生任何影响,当该键被惰性删除或者定期删除之后,程序会向AOF文件追加一条DEL
命令,来显式记录该键已被删除
- 试图获取过期键
zhishi
,会有以下三个动作:- 从数据库中删除
zhishi
键 - 追加一条
DEL zhishi
命令到AOF文件 - 向执行 GET命令的客户端返回空回复
- 从数据库中删除
AOF重写
AOF是将执行的写命令添加到AOF文件的末尾来记录数据的变化;为了避免文件被添加得越来越大,甚至有可能用完硬盘的所有空间,因此Redis提供了Rewrite
的优化策略,分别是REWRITEAOF
和BGREWRITEAOF
,两个命令的区别也是在于是否阻塞主进程,这两个命令都不会将数据空间中的过期键给保存到AOF文件中;
主从复模式下对过期键的处理
复制模式下,从服务器的过期键删除动作由主服务控制
- 主服务器在删除一个过期键之后,会显式地向所有从服务器发送一个
DEL
命令,告知从服务器删除这个过期键 - 从服务器在执行客户端发送过来的读命令时,即使碰到过期键也不会删除,而是继续向处理未过期键一样来处理过期键
- 从服务器只有接收到主服务器发送过来的DEL命令之后,才会删除过期键
- 通过由主服务器来控制从服务器统一地删除过期键,可以保证主从服务器数据一致性,也正是因为这个原因,当一个过期键仍然存在于主服务器时,这个过期键在从服务器中的复制品也会继续存在
本文参考
- 《Redis设计与实现》
本文若有任何看不懂,或者有错误的地方欢迎大家评论区留言,我时时关注哦