对于过期键一般有三种删除策略

• 定时删除：在设置键的过期时间的同时，创建一个定时器(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过期了，它就会做得更多。