Redis里给值定时不拖延，超时设置马上生效的那些事儿

开始）

这篇文章的想法主要来自于我在日常使用Redis时遇到的一个实际问题,以及后来在Redis的官方文档和一些技术社区，比如Stack Overflow上的相关讨论中寻找到的解答，我记得当时的问题是：我给Redis里的一个键设置了过期时间，但为什么感觉它没有立刻消失？这个问题引导我深入了解了Redis的过期机制。

很多人可能和我一开始想的一样,觉得在Redis里用EXPIRE命令或者SET key value EX seconds`给一个键设置个过期时间，比如10秒，那么Redis肯定会开启一个精确的倒计时，10秒一到，“啪”的一声，这个键就被立刻删除了，就好像我们手机里的倒计时闹钟一样准点，但实际情况是，Redis为了平衡性能和效率，采用了一套更聪明但也更复杂的策略，它并不是为每一个有过期时间的键都单独安排一个“看守”。

Redis处理过期键的核心机制,主要依赖两种方法结合着来，用术语说叫做“被动过期”和“主动过期”，别被名字吓到，我用大白话解释一下。

被动过期，也叫惰性过期，这个最好理解，就是说，Redis不会主动去检查一个键是否到期了，它特别“懒”，这个“懒”其实是种聪明的设计，只有当客户端尝试去访问这个键的时候，Redis才会顺便看一眼这个键的“身份证”，检查一下它有没有过期时间，如果设置了，再看看现在是不是已经超时了，你执行了一个GET mykey命令，Redis在返回数据之前，会先判断一下mykey有没有过期，如果过期了，它立刻就会把这个键删除掉，然后给你返回一个空值，好像这个键从来不存在一样，这时候，效果就是“立刻”的，你访问的那一刻，删除就发生了。

被动过期的“立刻生效”是体现在读取操作上的，对于应用来说，你永远读不到过期的数据，因为在你读的时候，如果它过期了，就会被当场处理掉，但这有个明显的漏洞：如果一个键过期之后，一直没人去访问它呢？那这个键就会一直留在内存里，成了永远不释放的垃圾，这肯定不行，所以Redis还需要一个兜底的机制。

这个兜底的机制就是主动过期，Redis会每隔一段时间，主动地抽查一部分设置了过期时间的键，然后把其中已经过期的键清理掉，这个过程是Redis内部自己定期执行的，不需要客户端触发。

关于这个主动过期的执行方式和频率,Redis官方文档里有详细的说明，它不是扫描所有键，那太慢了，而是随机抽取一些键进行检查，这个过程每秒会执行很多次（默认10次），它采用了自适应算法：如果发现本轮抽查中过期的键比例很高，它会立刻启动新一轮的抽查，直到过期的键变得稀少为止，这样能确保在大量键集中过期时（比如一场促销活动结束，大量缓存同时失效），Redis能快速回收内存。

回到“马上生效”这个问题上，通过上面的解释，我们可以总结出：

1. 对于读操作：过期是绝对“立刻生效”的，只要你去读，Redis保证返回的不是过期数据，超时设置在那一个精确的时刻被兑现。

2. 对于内存回收：过期“生效”会有微小的延迟，一个键在到期后，如果一直不被访问，它需要等到下一次主动过期循环被随机抽中，才会被删除，这个延迟通常非常短，在Redis负载正常的情况下，最多也就延迟那么一秒左右，因为主动过期的频率很高，对于绝大多数应用场景，这个延迟是完全可以接受的。

有没有办法实现真正意义上的、从设置那一刻起就严格精确的过期呢？其实也有变通的办法，你可以不依赖Redis的过期时间，而是把过期时间戳作为值的一部分存起来，每次读取的时候，应用层自己检查一下时间戳是否已过时，如果过了，就自己执行删除并处理后续逻辑，但这增加了客户端的复杂性，一般只在有极端精确性要求的场景下才需要考虑。

Redis的过期策略是一种在精确性和性能之间取得的完美平衡,它保证了数据的一致性（你读到的绝不是脏数据），又以很小的延迟代价换来了极高的处理性能，理解了这一点，我们就能更放心地使用Redis的过期功能，也知道在哪些边界情况下需要特别注意。 结束）