Redis（五）：过期key删除策略

1、Redis 中 key 过期的设置

通过 EXPIRE 命令 或者 PEXPIRE 命令， 客户端可以以秒或者毫秒精度为数据库中的某个键设置 生存时间（Time To Live，TTL），在经过指定的秒数或者毫秒数之后，服务器就会自动删除生存时间为 0 的键：

127.0.0.1:6379> setex hello 15 world 
OK
127.0.0.1:6379> ttl hello
(integer) 11
127.0.0.1:6379> ttl hello
(integer) 9
127.0.0.1:6379> ttl hello
(integer) 8
127.0.0.1:6379> ttl hello
(integer) 4
127.0.0.1:6379> ttl hello
(integer) -2


127.0.0.1:6379> set hello world
OK
127.0.0.1:6379> expire hello 10
(integer) 1
127.0.0.1:6379> ttl hello
(integer) 6
127.0.0.1:6379> ttl hello
(integer) 3
127.0.0.1:6379> ttl hello
(integer) -2

2、过期key删除策略

2.1、定时删除

在设置key的过期时间的同时，为该key创建一个定时器，让定时器在key的过期时间来临时，对key进行删除

2.1.1、优点

定时删除策略对内存是友好的，通过使用定时器，定时删除策略可以保证过期键会尽可能快的被删除，并释放过期键所占用的内存。

2.1.2、缺点

定时删除策略对CPU是不友好的，在过期键比较多的情况下，删除过期键可能会占用一部分CPU时间，在内存不紧张但是CPU 紧张的情况下，将 CPU 时间用在删除和当前任务无关的过期键上，无疑会对服务其的响应时间和吞吐量造成影响。

除此之外，创建一个定时器需要用到 Redis 服务器中的时间事件，而当前时间事件的实现方式 —— 无序链表，查找一个事件的时间复杂度为 O（N），并不能 高效 地处 理 大量 时间 事件。

2.2、惰性删除

每次从数据库获取 key 的时候去检查是否过期，如果过期，就删除该键；否则，就返回该键。

2.2.1、优点

惰性删除策略对 CPU 时间是最友好的，程序会在获取键时才对键进行过期检查，并且删除的目标仅限于当前处理的键，这个策略不会再删除其他无关的过期键上花费 CPU 时间。

2.2.2、缺点

惰性删除策略对内存时最不友好的，如果一个键已经过期，只要这个键不被删除，它所占用的内存就不会被释放。如果数据库中有很多的过期键，而这些过期键又没有被访问到的话，那么他们永远都不会被删除，除非手动执行 flushdb。

2.3、定期删除

每隔一段时间，程序就对数据库进行检查，删除里面的过期键。

2.3.1、优点

定期删除策略是前两种策略的一种整合和折中：

• 定期删除策略每隔一段时间执行一次删除过期键操作，并通过限制删除操作执行的时长和频率来减少删除操作对 CPU 时间的影响。
• 定期删除策略有效地减少了因为过期键而带来的内存浪费。

2.3.2、缺点

• 如果删除操作执行的太频繁，或者执行的时间太长，定期删除策略就会退化成定时删除策略，以至于将CPU时间过多的消耗再删除过期键上面。
• 如果删除操作执行的太少，或者执行的时间太短，定期删除策略又会和惰性删除策略一样，出现浪费内存的情况。

3、Redis 采用的过期键删除策略

Redis 服务其使用的是惰性删除和定期删除两种策略，通过配合使用这两种删除策略，服务其可以很好的合理利用CPU时间和避免浪费内存空间之间取得平衡。

4、RDB 持久化功能对过期键的处理

4.1、生成 RDB 文件

在执行SAVE 命令或者 BGSAVE 命令创建一个新的 RDB 文件时，程序会对数据库中的键进行检查，已过期的键不会被保存到 新创建的 RDB 文件中。

4.2、载入 RDB 文件

在启动 Redis 服务器时，如果服务器开启了 RDB 功能，那么服务器将对 RDB 文件进行载入：

• 如果服务器以主服务器模式运行，那么在载入 RDB 文件时，程序会对文件中保存的键进行检查，未过期的键会被载入到数据库中，而过期键则会被忽略，所以过期键对载入RDB 文件的主服务器不会造成影响。
• 如果服务器以从服务器模式运行，那么在载入 RDB 文件时，文件中保存的所有键，不论是否过期，都会被载入到数据库中。不过，因为主从服务器在进行数据同步的时候，从服务器的数据库就会被清空，所以一般来讲，过期键对载入 RDB 文件的从服务器也不会造成影响。

5、AOF 持久化功能对过期键的处理

5.1、AOF 文件写入

当服务器以 AOF 持久化模式运行时， 如果数据库中的某个键已经过期，但它还没有被惰性删除或者定期删除，那么 AOF文件不会因为这个过期键而产生任何 影响。 当过期键被惰性删除或者定期删除之后，程序会向 AOF 文件追加（append）一条 DEL 命令，来显式地记录该键已被删除。

5.2、AOF 文件重写

和生成 RDB 文件时类似，在执行 AOF 重写的过程中，程序会对数据库中的键进行检查，已过期的键不会被保存到重写后的 AOF 文件中。

6、Replication 复制对过期键的处理

过期删除操作统一在 master 实例中进行并向下传递，而不是各 salve 各自处理。这样一来便不会出现数据不一致的情形。

当 slave 连接到 master 后并不能立即清理已过期的 key（需要等待由master传递过来的DEL操作），slave 仍需对数据集中的过期状态进行管理维护以便于在 slave 被选为 master 时能像 master 一样独立的进行过期处理。