-
Redis简介
-
Cache的过期策略有哪些
-
Redis的过期键删除策略：情性删除和定期删除
-
小结：鞋合不合适,只有脚知道
众所周知，Redis是缓存中间件领域中的无冕之王。
来个灵魂拷问：缓存解决能解决什么问题呢？
把热数据存放到存取速度快的存储介质中，通过空间换时间的方式来提升数据的存取速度。
存取速度快的存储介质都会贵一些，贵的东西肯定要省着点用。
那么，如何节省缓存空间呢？
让缓存过期。
当前时间到达过期时间时，将删除缓存，减少空间的占用；
如果缓存空间已满，则根据配置的maxmemory-policy来决定如何腾出新的空间以继续提供读写服务。
在聊Redis的Redis的过期键删除策略之前，我们不妨发散一下：
Cache的过期策略有哪些
Redis所有的数据结构都可以设置过期时间，时间一到，就会被自动删除。
你可以想像Redis内部有一个死神，他时刻盯着所有设置了过期时间的key,寿命一到就会立即“收割”。
如果让你来设计Redis的过期键删除策略，你会怎么设计呢？
怎么设计？这个问题翻译一下：
如果一个键过期了，那么它什么时候被删除是最合适的呢？
这个问题有三种可能的答案，它们分别代表了三种不同的删除策略：
-
定时删除 ：在设置键的过期时间的同时，创建一个定时器（timer），让定时器在键的过期时间来临时，立即执行对键的删除操作。
-
惰性删除 ：放任键过期不管，但是每次从键空间中获取键时，都检查取得的键是否过期，如果过期的话，就删除该键；如果没有过期，就返回该键。
-
定期删除 ：每隔一段时间，程序就对数据库进行一次检查，删除里面的过期键。至于要删除多少过期键，以及要检查多个数据库，则由算法决定 。
在这三种策略中，第一种和第三种为主动删除策略，而第二种则为被动删除策略。
定时删除
定时删除策略对内存是最友好的：通过使用定时器，定时删除策略可以保证过期键会尽可能快地被删除，并释放过期键所占用的内存。
另一方面，定时删除策略的缺点是，它对CPU时间是最不友好的：在过期键比较多的情况下，删除过期键这一行为可能会占用相当一部分CPU时间，在内存不紧张但是CPU时间非常紧张的情况下，将CPU时间用在删除和当前任务无关的过期键上，无疑会对服务器的响应时间和吞吐量造成影响。
例如，如果正有大量的命令请求在等待服务器处理，并且服务器当前不缺少内存，那么服务器应该优先将CPU时间用在处理客户端的命令请求上面，而不是用在删除过期键上面。
除此之外，创建一个定时器需要用到Redis服务器中的时间事件，而当前时间事件的实现方法--无序链表，查找一个事件的时间复杂度为O(N)--并不能高效地处理大量时间事件。
因此，要让服务器创建大量的定时器，从而实现定时删除策略，在现阶段来说并不现实。
惰性删除
惰性删除策略对CPU时间来说是最友好的：程序只会在取出键时才对键进行过期检查，这可以保证删除过期键的操作只会在非做不可的情况下进行，并且删除的目标仅限于当前处理的键，这个策略不会在删除其他无关的过期健上花费任何CPU时间。
惰性删除策略的缺点是，它对内存是最不友好的：如果一个键已经过期，而这个键又仍然保留在数据库中，那么只要这个过期键不被删除，它所占用的内存就不会释放。
在使用惰性删除策略时，如果数据库中有非常多的过期键，而这些过期键又恰好没有被访问到的话，那么它们也许永远也不会被删除（除非用户手动执行FLUSHDB），我们甚至可以将这种情况看作是一种内存泄漏——无用的垃圾数据占用了大量的内存，而服务器却不会自己去释放它们，这对于运行状态非常依赖于内存的Redis 服务器来说，肯定不是一个好消息。
举个例子，对于一些和时间有关的数据，比如日志（log），在某个时间点之后，对它们的访问就会大大减少，甚至不再访问，如果这类过期数据大量地积压在数据库中，用户以为服务器已经自动将它们删除了，但实际上这些键仍然存在，而且键所占用的内存也没有释放，那么造成的后果肯定是非常严重的。
定期删除
从上面对定时删除和惰性删除的讨论来看，这两种删除方式在单一使用时都有明显的缺陷：
□定时删除占用太多CPU时间，影响服务器的响应时间和吞吐量。
□惰性删除浪费太多内存，有内存泄漏的危险。
定期删除策略是前两种策略的一种整合和折中：
□定期删除策略每隔一段时间执行一次删除过期键操作，并通过限制删除操作执行的 时长和频率来减少删除操作对CPU时间的影响。
□除此之外，通过定期删除过期键，定期删除策略有效地减少了因为过期键而带来的 内存浪费。
定期删除策略的难点是确定删除操作执行的时长和频率：
□如果删除操作执行得太频繁，或者执行的时间太长，定期删除策略就会退化成定时 删除策略，以至于将CPU时间过多地消耗在删除过期键上面。
□如果删除操作执行得太少，或者执行的时间太短，定期删除策略又会和惰性删除策 略一样，出现浪费内存的情况。
因此，如果采用定期删除策略的话，服务器必须根据情况，合理地设置删除操作的执行时长和执行频率。
redisDb结构的expire字典保存了数据库中所有键的过期时间，我们称这个字典为过期字典： 过期字典的键是一个指针，这个指针指向键空间中的某个键对象（也即是某个数据库键）。
过期字典中的值是一个long long类型的整数，这个整数保存了键所指向的数据库键的过期时间---一个毫秒精度的UNIX时间戳。
当对一个键执行PERSIST命令执行之后，过期字典中这个键值对就消失了。
过期的判定，通过过期字典，程序可以用以下步骤检查一个给定键是否过期：
step1:检查给定键是否存在于过期字典：如果存在，那么返回键的过期时间。
step2:检查当前UNIX时间戳是否大于键的过期时间：
step3:如果是的话，那么键已经过期 ；否则的话，键未过期 。
实现过期键判定的另一种方法是使用TTL命令或者PTTL命令，如果对某个键执行TTL命令，并且命令返回的值大于等于0，那么说明该未过期。
如果同一时间太多的key过期，以至于Redis忙不过来？同时因为Redis是单线程的，"收割过期缓存"的时间也会占有线程的处理时间，如果"收割"的操作太过繁忙，会不会导致线上读写指令出现卡顿？
这些问题Antirez早就想到了，所以在过期问题上，Redis非常小心。
Redis服务器实际使用的是情性删除和定期删除两种策略。
通过配合使用这两种删除策略，服务器可以很好地在合理使用CPU时间和避免浪费内存空间之间取得平衡。
Redis会将每个设置了过期时间的key放入一个独立的字典【过期字典】中，以后会定期遍历这个字典来删除到期的key。除了定时遍历之外，它还会使用惰性策略来删除过期的key。所谓惰性策略就是在客户端访问这个key的时候，Redis对key的过期时间进行检查，如果过期了就立即删除。如果说定期删除是集中处理，那么惰性删除就是零散处理。
Redis默认每秒进行10次过期扫描，过期扫描不会遍历过期字典中所有的key，而是采用了一种简单的贪心算法，步骤如下。
（1）从过期字典中随机选出20个key。
（2）删除这20个key中已经过期的key。
（3）如果过期的key的比例超过1/4，那就重复步骤（1）。
同时，为了保证过期扫描不会出现过度循环，导致线程卡死的现象，算法还增加了扫描时间的上限，默认不会超过25ms。
假设一个大型的Redis实例中所有的key在同一时间过期了，会出现怎么的结果呢？
毫无疑问，Redis会持续扫描过期字典（循环多次），直到过期字典中过期的key变得稀疏，才会停止（循环次数明显下降）。这就会导致线上读写请求出现明显的卡顿的现象。导致这种卡顿的另外一种原因是内存管理器需要频繁回收内存页，这也会产生一定的CPU消耗。
当客户端请求到来时，服务器如果正好进入过期扫描状态，客户端的请求将会等待至少25ms后才会进行处理，如果客户端将超时时间设置得比较短，比如10ms，那么就会出现大量的链接因为超时而关闭，业务端就会出现很多异常，而且这时你还无法从Redis的slowlog中看到慢查询记录，因为慢查询指的是逻辑处理过程慢，不包含等待时间。
所以业务开发人员一定要注意过期时间，如果有大批量的key过期，要给过期时间设置一个随机范围，而不能全部在同一时间过期。
# 在目标过期时间上增加一天的随机时间
redis.expire_at(key,random.randint(86400)+expire_ts)
在一些活动系统中，因为活动是一期一会，下一期活动举办时，前面几期活动的很多数据都可以丢弃了，所以需要给相关的活动数据设置一个过期时间，以减少不必要的Redis内存占用。如果不加注意，你可能会将过期时间设置为活动结束时间再增加一个常量的冗余时间，如果参与活动的人数太多，就会导致大量的key同时过期。
从节点不会进行过期扫描，从节点对过期的处理是被动的。主节点在key到期时，会在AOF文件里增加一条del命令，同步到所有的从节点，从节点通过执行这条del指令来删除过期的key。
小结：鞋合不合适,只有脚知道
一个技术方案是否合适，取决于要解决的问题。
Redis的卖点是快，是高性能，那么在过期键删除策略就很明确了：
情性删除策略和定期删除策略。
只有这样，Redis服务器才可以很好地在合理使用CPU时间和避免浪费内存空间之间取得平衡。
留个问题：
用Redis实现过期订单关闭，是否合适？
参考
《Redis深度历险 核心原理与应用实践》
《Redis设计与实现》
