Redis过期键的删除策略

Redis中有个设置时间过期的功能，即对存储在 redis 数据库中的值可以设置一个过期时间。作为一个缓存数据库，这是非常实用的。如我们一般项目中的 token 或者一些登录信息，尤其是短信验证码都是有时间限制的，按照传统的数据库处理方式，一般都是自己判断过期，这样无疑会严重影响项目性能。

我们 set key 的时候，都可以给一个 expire time，就是过期时间，通过过期时间我们可以指定这个 key 可以存活的时间。

注：对于散列表这种容器，只能为整个键设置过期时间（整个散列表），而不能为键里面的单个元素设置过期时间。

如果一个键是过期的，那它到了过期时间之后是不是马上就从内存中被被删除呢？如果不是，那过期后到底什么时候被删除呢？

其实有三种不同的删除策略：

1. 立即删除。在设置键的过期时间时，创建一个回调事件，当过期时间达到时，由时间处理器自动执行键的删除操作。
2. 惰性删除。键过期了就过期了，不管。每次从dict字典中按key取值时，先检查此key是否已经过期，如果过期了就删除它，并返回nil，如果没过期，就返回键值。
3. 定时删除。每隔一段时间，对expires字典进行检查，删除里面的过期键。

可以看到，第二种为被动删除，第一种和第三种为主动删除，且第一种实时性更高。下面对这三种删除策略进行具体分析。

立即删除

立即删除能保证内存中数据的最大新鲜度，因为它保证过期键值会在过期后马上被删除，其所占用的内存也会随之释放。但是立即删除对cpu是最不友好的。因为删除操作会占用cpu的时间，如果刚好碰上了cpu很忙的时候，比如正在做交集或排序等计算的时候，就会给cpu造成额外的压力。

而且目前redis事件处理器对时间事件的处理方式–无序链表，查找一个key的时间复杂度为O(n),所以并不适合用来处理大量的时间事件。

惰性删除

惰性删除是指，某个键值过期后，此键值不会马上被删除，而是等到下次被使用的时候，才会被检查到过期，此时才能得到删除。所以惰性删除的缺点很明显:浪费内存。dict字典和expires字典都要保存这个键值的信息。

举个例子，对于一些按时间点来更新的数据，比如log日志，过期后在很长的一段时间内可能都得不到访问，这样在这段时间内就要拜拜浪费这么多内存来存log。这对于性能非常依赖于内存大小的redis来说，是比较致命的。

定时删除

从上面分析来看，立即删除会短时间内占用大量cpu，惰性删除会在一段时间内浪费内存，所以定时删除是一个折中的办法。

Redis服务器定时随机的测试key的过期时间，如果过期了则被动删除。被动删除的存在必不可少，因为存在一些过期且永久不在访问的key，如果都依赖主动删除，那么它们将会永久占用内存。
Redis为了保证提供高性能服务，被动删除过期的key，采用了贪心策略/概率算法，默认每隔10秒扫描一次，具体策略如下：

1. 从过期字典（设置了过期时间的key的集合）中随机选择20个key，检查其是否过期
2. 删除其中已经过期的key
3. 如果删除的过期key数量大于25%，则重复步骤1

如何正确的设置key的过期时间

开发在设计Redis缓存架构时，一定要注意要尽可能的避免（禁止）将大量的key设置为同一过期时间，因为结合2.2被动删除可知，Redis被动删除过期key时，会导致服务短暂的不可用；如果存在大量key同时过期，这会导致被动删除key的三个步骤循环多次，从而导致Redis服务出现卡顿情况，这种情况在大型流量项目是无法接收的。

因此为了避免这种情况出现，一定要将一些允许过期时间不需要非常精确的key，设置较为随机的过期时间，这样就可以将卡顿时间缩小

从节点存在的问题

在主从模式下，Redis是AP架构，它具有高可用性，但是无法保证主从节点的强一致性。在Redis主从架构中，从节点不会直接发生数据的写入，过期key删除也不会在从节点直接发生，它只能被动地依靠主从同步来完成这一步骤。

当主节点中key到期时，会在AOF文件中增加DEL指令，在这个指令未同步到从节点这段时间内，从节点中的key仍然是未删除的。只有当指令同步过来之后，从节点才会删除这个key。通常情况下，这并不带来什么太大的问题，但是确实存在主从数据不一致的情况。

Redis使用的策略

redis使用的过期键值删除策略是：惰性删除加上定期删除，两者配合使用。