谈谈Redis针对键生存时间以及过期的处理

一直以来，我对redis中对键的生存时间以及过期键的处理甚感兴趣，以前从没有去深入了解，在看了黄健宏写的《Redis设计与实现》后，突然醍醐灌顶，恍然大悟，并不得不感叹作者设计的巧妙。仅以此文章，记录一下读后的收获。

关于键的生存时间或过期时间设置

通过命令EXPIRE或PEXPIRE，客户端可以以秒或者毫秒精度为数据库中的某个键设置生存时间，那么，redis是如何存储这些“特殊”的键值对呢？又是如何实现的呢？
redis中提供了4中命令用于设置键的生存时间或过期时间(键在哪个时间被删除)，虽然提供了多种形式的设置命令，但最终都是转化成一个PEXPIREAT命令(将键设置为指定的毫秒数时间戳)，见下图：

操作如下：

redis在底层有个expire字典，该字典保存了数据库中所有键的过期时间，其中

• 过期字典的键是一个指针，该指针指向键空间的某个键对象
• 过期字典的值是long long类型的整数，这个整数保存了键所指向的数据库过期时间---- 一个毫秒精度的unix时间戳

关于过期键的处理

按照现实的场景，假如一个键过期了，那么我们怎么删除它呢？不难想到，我们可能有如下的三种可能的方案：

1. 定时删除：创建一个定时器，高频地对键进行扫描，对于已过期的键执行删除操作
2. 惰性删除：每当从键空间取键时，检查取得键是否过期，若过期，则执行删除，如果没过期，则正常返回
3. 定期删除：定期对整个数据库做一个check， 删除里面的过期键

思考，以上三种策略中，第一与第三种为主动删除策略，第二种为被动删除策略，那么它们各自有什么特点呢？

定时删除

定时删除策略很明显对内存是最友好的，通过使用定时器，定时删除策略可以保证过期键会被尽快地干掉，并释放过期键占用的内存。当然缺点也很明显，对CPU相当不友好。服务器中过期键比较多时，删除过期键的操作本身就会消耗很多cpu时间。当服务器中过期键比较少时，不断地检索未过期的key也会占用相当一部分cpu时间

惰性删除

惰性删除就简单了，程序只会在被取到时才对键进行检查，这个策略保证了删除的目标仅限于当前处理的键，不会在删除其他过期键上花费任何cpu时间。虽然对cpu友好，但对内存来说，这是个灾难。如果服务器中恰巧有很多过期的键，且一直未被访问到，且这种key会随时间一直递增，这些数据在某种程度上算是垃圾数据，理应删除的，但由于一直存在，会消耗大量的服务器内存，最终服务器会不堪重负，内存耗尽而挂掉。

定期删除

从上面的两种策略来看，这两种中的任意一种在单一使用时，都会存在非常明显的缺点

• 定时删除占用太多cpu时间，影响服务器的响应时间和吞吐量
• 惰性删除浪费太多内存，有内存泄露的风险

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

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

定期删除的难点在于确定删除操作执行的时长和频率：

• 如果删除操作执行得很频繁，或者执行的时间过长，则定期删除策略就会退化为定时删除策略
• 如果删除操作执行得太少，或者执行时间比较短，则又退化为惰性删除，出现浪费内存的现象

Redis 的过期键删除策略

redis实际使用的惰性删除+定期删除两种策略，通过配合使用这两种删除策略可以很好地在合理使用cpu时间和避免浪费内存之间取得平衡。惰性删除和定期删除的策略实现，可见原文第九章。

总结：

1. 键生存时间的设定是依靠过期字典，过期字典存的是key 和对应失效时间的unix毫秒时间戳，判断是否过期以及ttl均通过计算实现
2. redis采取惰性删除+定期删除的方式实现对过期键的处理(原文对serverCron函数的设置和依据没有做过多阐述，也就是定期删除执行的时长和频率这块没有做更细的阐述)，如何合理设置定期删除的周期有待继续探究