Redis的过期键删除策略

• 定时删除

对内存最友好：通过定时器，保证过期键会尽可能快地被删除，并释放过期键所占用的内存。

另一方面，缺点是，对 CPU 时间最不友好：在过期键较多的情况下，删除过期键这一行为可能会占用相当一部分 CPU 时间，在内存不紧张但是 CPU 时间非常紧张的情况下，将 CPU 时间用在删除和当前任务无关的过期键，无疑会对服务器的响应时间和吞吐量造成影响。

eg. 如果正有大量的命令请求在等待服务器处理，并且服务器当前不缺少内存，那么服务器应该优先将 CPU 时间用在处理客户端的命令请求上面。

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

因此要让服务器创建大量的定时器，从而实现定时删除策略，在现阶段来说不现实。

• 惰性删除

对 CPU 时间最友好：程序只会在取出键时才对键进行过期检查，保证删除过期键的操作只会在非做不可的情况下进行，并且删除的目标仅限于当前处理的键，不会在删除其他无关的过期键上花费任何 CPU 时间。

缺点是，对内存是最不友好的：如果一个键已经过期，而这个键又仍然保留在数据库中，那么只要这个过期键不被删除，它所占用的内存就不会释放。

在使用惰性删除策略时，如果数据库中有非常多的过期键，而这些过期键又恰好没有被访问到的话，那么它们也许不会被删除（除非用户手动执行FLUSHDB），我们甚至可以将这种情况看作一种内存泄漏——无用的垃圾数据占用大量的内存，而服务器却不会自己释放它们，这对于运行状态非常依赖于内存的 Redis 服务器来说，肯定不是一个好消息。

eg. 对于一些和时间有关的数据，比如日志（log），在某个时间点之后，对它们访问会大大减少，甚至不再访问，如果这类过期数据大量地积压在数据库中，用户以为服务器已经自动删除它们了，但实际上这些键仍然存在，内存也没有释放，后果肯定非常严重。

• 定期删除

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

而它的难点是确定删除操作执行的时长和频率：
1. 太频繁或执行时间太长，会退化成定时删除策略；
2. 执行得太少，或者执行的时间太少，定期删除策略又会和惰性删除策略一样，出现浪费内存情况。

• Redis的过期键删除策略

Redis 服务器实际上使用的是惰性删除和定期删除两种策略。在内存和 CPU 时间之间平衡。