redis 过期数据

https://www.jianshu.com/p/60cc093d6c36

https://blog.youkuaiyun.com/tuesdayma/article/details/79029245

 

redis的三种删除策略：

1、被动删除：在上一章中已经提到过，dbsize中获得key个数包含过期的key，只有在key再次被操作的时候，redis才会去检测该key是否已经过期，如果过期则将它删除，这对于cpu来说，能节约出删除该key的时间来；但是对于内存来说，假如该key一直甚至永远不被调用的话，它将一直占着内存，当这种key越来越多的时候，内存会被这种可以称得上是垃圾key占满，对于吃内存的redis而言，无疑是一场噩梦。

2、主动删除：主要由redis.c/serverCron来实现，作为时间事件来进行，每隔一段时间就会自动运行一次，serverCron 会一直定期执行，直到服务器关闭为止。配置文件中的hz就是用来配置这个的频率的，默认是10，表示serverCron每秒执行10次。

3、maxmemory 删除：当前已用内存超过maxmemory限定时，将会触发。有6策略

过期数据删除策略

 redis的过期数据删除策略使用了惰性删除和定期删除两种策略：

• 惰性删除发生在redis处理读写请求的过程，如get/set等命令。
• 定期删除发生在redis内部定时任务执行过程中，限制占用cpu的时间。

LRU配置参数

Redis配置中和LRU有关的有三个：

• maxmemory: 配置Redis存储数据时指定限制的内存大小，比如100m。当缓存消耗的内存超过这个数值时, 将触发数据淘汰。该数据配置为0时，表示缓存的数据量没有限制, 即LRU功能不生效。64位的系统默认值为0，32位的系统默认内存限制为3GB
• maxmemory_policy: 触发数据淘汰后的淘汰策略
• maxmemory_samples: 随机采样的精度，也就是随即取出key的数目。该数值配置越大, 越接近于真实的LRU算法，但是数值越大，相应消耗也变高，对性能有一定影响，样本值默认为5。

淘汰策略

淘汰策略即maxmemory_policy的赋值有以下几种：

• noeviction:如果缓存数据超过了maxmemory限定值，并且客户端正在执行的命令(大部分的写入指令，但DEL和几个指令例外)会导致内存分配，则向客户端返回错误响应
• allkeys-lru: 对所有的键都采取LRU淘汰
• volatile-lru: 仅对设置了过期时间的键采取LRU淘汰
• allkeys-random: 随机回收所有的键
• volatile-random: 随机回收设置过期时间的键
• volatile-ttl: 仅淘汰设置了过期时间的键---淘汰生存时间TTL(Time To Live)更小的键
• 从Redis版本4.0开始，引入了新的LFU（最不常用）驱逐策略

要配置LFU模式，可以使用以下策略：

• volatile-lfu 使用具有过期集的密钥在近似的LFU中进行驱逐。
• allkeys-lfu 使用近似的LFU退出任何密​​钥。

LFU近似于LRU：它使用概率计数器（称为莫里斯计数器），以便仅使用每个对象的几个位来估计对象访问频率，并结合衰减周期，从而使计数器随时间而减少：在某个时候，我们不再希望将密钥视为频繁访问的密钥，即使它们是过去的密钥也是如此，因此该算法可以适应访问模式的转变。

volatile-lru, volatile-random和volatile-ttl这三个淘汰策略使用的不是全量数据，有可能无法淘汰出足够的内存空间。在没有过期键或者没有设置超时属性的键的情况下，这三种策略和noeviction差不多。

一般的经验规则:

• 使用allkeys-lru策略：当预期请求符合一个幂次分布(二八法则等)，比如一部分的子集元素比其它其它元素被访问的更多时，可以选择这个策略。
• 使用allkeys-random：循环连续的访问所有的键时，或者预期请求分布平均（所有元素被访问的概率都差不多）
• 使用volatile-ttl：要采取这个策略，缓存对象的TTL值最好有差异

volatile-lru 和 volatile-random策略，当你想要使用单一的Redis实例来同时实现缓存淘汰和持久化一些经常使用的键集合时很有用。未设置过期时间的键进行持久化保存，设置了过期时间的键参与缓存淘汰。不过一般运行两个实例是解决这个问题的更好方法。

为键设置过期时间也是需要消耗内存的，所以使用allkeys-lru这种策略更加节省空间，因为这种策略下可以不为键设置过期时间。

近似LRU算法

我们知道，LRU算法需要一个双向链表来记录数据的最近被访问顺序，但是出于节省内存的考虑，Redis的LRU算法并非完整的实现。Redis并不会选择最久未被访问的键进行回收，相反它会尝试运行一个近似LRU的算法，通过对少量键进行取样，然后回收其中的最久未被访问的键。通过调整每次回收时的采样数量maxmemory-samples，可以实现调整算法的精度。

根据Redis作者的说法，每个Redis Object可以挤出24 bits的空间，但24 bits是不够存储两个指针的，而存储一个低位时间戳是足够的，Redis Object以秒为单位存储了对象新建或者更新时的unix time，也就是LRU clock，24 bits数据要溢出的话需要194天，而缓存的数据更新非常频繁，已经足够了。

Redis的键空间是放在一个哈希表中的，要从所有的键中选出一个最久未被访问的键，需要另外一个数据结构存储这些源信息，这显然不划算。最初，Redis只是随机的选3个key，然后从中淘汰，后来算法改进到了N个key的策略，默认是5个。

Redis3.0之后又改善了算法的性能，会提供一个待淘汰候选key的pool，里面默认有16个key，按照空闲时间排好序。更新时从Redis键空间随机选择N个key，分别计算它们的空闲时间idle，key只会在pool不满或者空闲时间大于pool里最小的时，才会进入pool，然后从pool中选择空闲时间最大的key淘汰掉。