浅谈Redis对于过期键的三种清除策略
目录
- Pre
- Redis Key的超时设置处理
- 被动删除
- 主动删除
- 当前已用内存超过maxmemory限定时,触发主动清理策略
对于过期键一般有三种删除策略
- 定时删除:在设置键的过期时间的同时,创建一个定时器(timer),让定时器在键的过期时间来临时,立即执行对键的删除操作;
- 惰性删除:放任键过期不管,但是每次从键空间中获取键时,都检查取得的键是否过期,如果过期的话,就删除该键;如果没有过期,那就返回该键;
- 定期删除:每隔一段时间,程序就对数据库进行一次检查,删除里面的过期键。至于删除多少过期键,以及要检查多少个数据库,则由算法决定。
下面我们来看看三种策略的优缺比较:
- 定时删除策略对内存是最友好的:通过使用定时器,定时删除策略可以保证过期键会尽可能快地被删除,并释放过期键所占用的内存;但另一方面,定时删除策略的缺点是,他对CPU是最不友好的:在过期键比较多的情况下,删除过期键这一行为可能会占用相当一部分CPU时间,在内存不紧张但是CPU时间非常紧张的情况下,将CPU时间用在删除和当前任务无关的过期键上,无疑会对服务器的响应时间和吞吐量造成影响;
- 惰性删除策略对CPU时间来说是最友好的:程序只会在取出键时才对键进行过期检查,这可以保证删除过期键的操作只会在非做不可的情况下进行;惰性删除策略的缺点是,它对内存是最不友好的:如果一个键已经过期,而这个键又仍然保留在数据库中,那么只要这个过期键不被删除,它所占用的内存就不会释放;
- 定时删除占用太多CPU时间,影响服务器的响应时间和吞吐量;惰性删除浪费太多内存,有内存泄漏的危险。定期删除策略是前两种策略的一种整合和折中:
- 定期删除策略每隔一段时间执行一次删除过期键操作,并通过限制删除操作执行的时长和频率来减少删除操作对CPU时间的影响;
- 通过定期删除过期键,定期删除策略有效地减少了因为过期键而带来的内存浪费;
- 定期删除策略的难点是确定删除操作执行的时长和频率。
Pre
Redis-17Redis内存回收策略
Redis Key的超时设置处理
expire key seconds
单位是秒。返回1成功,0表示key已经设置过过期时间或者不存在。 如果想消除超时则使用persist key。如果希望采用绝对超时,则使用expireat命令。
ttl key
返回设置过过期时间的key的剩余过期秒数 -1表示没有设置过过期时间,对于不存在的key,返回-2。
pexpire key 毫秒数
设置生命周期。
pttl key
以毫秒返回生命周期。
被动删除
当读/写一个已经过期的key时,会触发惰性删除策略,直接删除掉这个过期key.
举个例子, set 一个 过期时间为 600s的 key , 当 到了 600s后,redis 并不会执行删除, 为了性能,redis 会在你下次访问的时候 去删除 。
这样的话,我如果永远不访问,那不歇菜了么? 不要着急,Redis还有主动删除 。
主动删除
由于惰性删除策略无法保证冷数据被及时删掉,所以Redis会定期主动淘汰一批已过期的key。
说白了,这就是定时任务干的活,防止有些key 一直占用内存。
当REDIS运行在主从模式时,只有主结点才会执行被动和主动这两种过期删除策略,然后把删除操作”del key”同步到从结点.
当前已用内存超过maxmemory限定时,触发主动清理策略
第三种策略的情况: 当前已用内存超过maxmemory限定时,会触发主动清理策略.
我们需要根据自身业务类型,选好maxmemory-policy(最大内存淘汰策略),设置好过期时间。如果不设置最大内存,当 Redis 内存超出物理内存限制时,内存的数据会开始和磁盘产生频繁的交换 (swap)会让 Redis 的性能急剧下降。
默认策略是volatile-lru,即超过最大内存后,在过期键中使用lru算法进行key的剔除,保证不过期数据不被删除,但是可能会出现OOM问题。
其他策略如下:
- allkeys-lru:根据LRU算法删除键,不管数据有没有设置超时属性,直到腾出足够空间 为止
- allkeys-random:随机删除所有键,直到腾出足够空间为止。
- allkeys-random:随机删除所有键,直到腾出足够空间为止。
- volatile-ttl:根据键值对象的ttl属性,删除最近将要过期数据。如果没有,回退到noeviction策略。
- noeviction:不会剔除任何数据,拒绝所有写入操作并返回客户端错误信息"(error)。OOM command not allowed when used memory",此时Redis只响应读操作
记住: volatile 开头的策略,只清理过期的key , 而all开头的策略则不管你过不过期,都会清理。
总结
- 当client主动访问key会先对key进行超时判断,过时的key会立刻删除。
- 从节点不会过期扫描,从节点对过期的处理是被动的。 在主从复制环境中,由于上述原因存在已经过期但是没有删除的key,在主snapshot时并不包含这些key,因此在slave环境中我们往往看到dbsize较master是更小的。
如果clien永远都不再get那条key呢?
redis会在Master的后台,每秒10次的执行如下操作:
随机选取100个key校验是否过期,如果有25个以上的key过期了,立刻额外随机选取下100个key(不计算在10次之内)。可见,如果过期的key不多,它最多每秒回收200条左右,如果有超过25%的key过期了,它就会做得更多。
到此这篇关于浅谈Redis对于过期键的三种清除策略的文章就介绍到这了,更多相关Redis 过期键清除内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们!