概述
数据库键的过期时间都保存在过期字典中，并且知道根据过期时间去判断一个键是否过期,剩下的问题是：如果一个键过期了，那么它什么时候会被删除呢?
这个问题有三种可能的答案，它们分别代表了三种不同的删除策略:
- 1.定时删除:在是个照顾键的过期时间的同时，创建一个定时器(timer)，让定时器在键的过期时间来临时，立即执行对键的删除操作
- 2.惰性删除:放任键过期不管，每次从键空间中获取键时，检查取得的键是否过期，如果过期的话，就删除该键；如果没有过期，就返回该键
- 3.定期删除:每隔一段时间，程序就对数据库进行一次检查，删除里面的过期键。至于要删除多少过期键，以及要检查多少个数据库，则由算法决定
在这三种策略中，第一种和第三种为主动删除策略，而第二种则为被动删除策略
定时删除
定时删除策略对内存时最优化的:通过使用定时器，定时删除策略可以保证过期键会尽快地被删除，并释放过期键所占用地内存。另一方面，定时删除策略的缺点就是，它是对CPU时间最不友好的，在过期键比较多的情况下，删除过期键这一行为可能会占用相当一部分CPU时间，在内存不紧张
但是CPU时间非常紧张的情况下，将CPU时间用在删除和当前任务无关的过期键上，无疑会对服务器的响应时间和吞吐量造成影响。
例子
例如，如果正有大量的命令请求在等待服务器处理，并且服务器当前不缺少内存，那么服务器应该优先将CPU时间用在处理客户端的命令请求上面，而不是用在删除过期键上面
除此之外，创建一个定时器需要用到Redis服务器中的时间事件，而当前事件事件的实现方式——无序链表，查找一个事件的事件复杂度为O(N)——并不能高效地处理大量时间事件。因此，要让服务器创建大量的定时器，从而实现定时删除策略，在现阶段来说并不现实
惰性删除
惰性删除策略对CPU事件来说是最友好的:程序只会在取出键时才对键进行过期检查，这可以保证删除过期键的操作只会在非做不可的情况下进行，并且删除的目标仅限当前处理的键，这个策略不会在删除其他无关的键上花费任何CPU事件。惰性删除的缺点是，它对内存是最不友好的，如果一个键已经过期，而这个键又仍然保留在数据库中，那么只要这个过期键不被删除，它所占用的内存就不会释放。在使用惰性删除策略时，如果数据库中有非常多的过期键，而这些过期键又恰好没有被访问到的话，
那么它们也许永远不会被删除(除非用户手动执行FLUSHDB)，我们甚至可以将这种情况看作是一种内存泄漏——无用的垃圾数据占用了大量的内存，而服务器却不会自己去释放它们，这对于运行状态非常依赖于内存的Redis服务器来说，肯定不是一个好消息
例子
举个例子，对于一些和时间相关的数据，比如日志(log)，在某个时间点之后，对他们的访问就会大大减少，甚至不再访问，如果这类过期数据大量地积压在数据库中，用户以为服务器已经自动将它们删除了，但实际上这些键仍然存在，而且键所占用地内存也没有放，那么造成的后果肯定是非常严重的。
定期删除。
从定时删除和惰性删除分析来看，这两种删除方式在单一使用时都有明显的缺陷:
- 1.定时删除占用太多CPU时间，影响服务器的响应时间和吞吐量
- 2.惰性删除浪费太多内存，有内存泄漏的危险
定期删除策略是前两种策略的一种整合折中：
- 1.定期删除策略每隔一段时间执行一次删除过期操作，并通过限制删除操作执行的时长和频率来减少删除操作对CPU时间的影响
- 2.除此之外，通过定期删除过期键，定期删除策略有效地减少了因为过期键而带来的内存浪费定期删除策略的难点是确定删除操作执行的时长和频率
- 1.如果删除操作执行得太频繁，或者执行的时间太长，定期删除策略就会退化成定时删除策略，以至于将CPU时间过多地消耗在删除过期键上面
- 2.如果删除操作执行得太少，或者执行的时间太短，定期删除策略又会和惰性删除策略一样，出现浪费内存的情况因此，如果采用定期删除策略的话，服务器必须根据情况，合理地设置删除操作地执行时长和执行频率