Redis Key过期机制解析与生产实践

1. Redis的Key过期机制初探

当我们在Redis中设置一个带过期时间的key时，这个key并不会在过期时刻被立即删除。Redis采用了一种独特的混合过期策略，这是很多开发者容易误解的地方。我曾在生产环境中遇到过因为对这个机制理解不透彻而导致的缓存穿透问题，后来通过深入研究源码和实际测试才彻底弄明白其中的门道。

Redis的过期策略主要由两种机制组成：被动过期和主动过期。被动过期发生在客户端尝试访问某个key时，Redis会先检查该key是否已过期，如果过期就立即删除。这种"惰性删除"的方式看似简单，但有个明显缺陷——如果某些key永远不被访问，即使它们已经过期也会一直占用内存空间。

关键理解：Redis的过期时间戳是存储在过期字典(expires dict)中的，这个字典与主字典平行存在，保存了所有设置过期时间的key及其对应的过期时间戳。

2. 主动删除策略的三种实现方式

2.1 定时删除的利与弊

定时删除是最直观的方案——为每个key设置一个定时器，到期立即删除。这种方案确实能保证key被及时清理，但想象一下如果有百万级key同时存在，就需要维护同等数量的定时器，这对内存和CPU都是巨大消耗。Redis作者Salvatore Sanfilippo在设计时明确否定了这种方案，因为它的资源消耗与key数量成正比，不适合高性能场景。

2.2 惰性删除的实际表现

惰性删除是Redis的基础策略，体现在db.c文件的expireIfNeeded函数中。每次执行命令前，Redis都会调用这个函数检查key是否过期。我做过一个测试：设置100万个带过期时间的key，然后只随机访问其中的10%。结果发现，未被访问的90%的key即使过期也会长期驻留内存，这正是惰性删除的典型表现。

2.3 定期删除的工作机制

为了弥补惰性删除的不足，Redis引入了定期删除策略。这个策略由activeExpireCycle函数实现，它会周期性(默认每秒10次)地随机抽取一定数量的过期key进行检查和删除。这个过程的详细步骤是：

1. 从每个数据库的过期字典中随机抽取20个key
2. 删除其中已过期的key
3. 如果过期key比例超过25%，则重复步骤1

这种抽样删除的方式既控制了CPU消耗，又能有效清理过期key。在实际运维中，我们可以通过调整hz参数来控制定期删除的频率，但要注意更高的频率意味着更多的CPU开销。

3. 内存淘汰策略与过期key的关系

当内存达到maxmemory限制时，Redis会触发内存淘汰策略。这与key过期机制密切相关但又有区别。Redis提供了8种淘汰策略，其中volatile-*系列策略只会淘汰设置了过期时间的key：

• volatile-lru：从已设置过期时间的key中使用LRU算法淘汰
• volatile-ttl：优先淘汰剩余生存时间(TTL)较短的key
• volatile-random：随机淘汰带过期时间的key

我曾在一个电商项目中遇到缓存雪崩问题，就是因为同时设置了大量key在相同时间点过期，加上使用了volatile-ttl策略，导致瞬间大量请求穿透到数据库。后来通过分散过期时间+使用allkeys-lru策略解决了这个问题。

4. 过期事件的监听与通知

Redis还提供了键空间通知功能，可以监听key的过期事件。要启用这个功能需要配置notify-keyspace-events参数，包含"Ex"选项。但要注意一个重要细节：过期事件是通过定期删除或惰性删除触发的，这意味着：

1. 如果某个key过期后一直未被访问，且未被定期删除扫描到，相关事件可能会延迟很久才触发
2. 事件通知不是实时的，存在不确定的延迟

在实现订单超时关闭功能时，我曾尝试依赖这个机制，后来发现不可靠，最终改用Redis的Streams数据结构实现了更精确的延迟处理。

5. 生产环境中的最佳实践

5.1 监控与调优建议

通过Redis的INFO命令可以获取关于过期key的重要指标：

• expired_keys：累计被删除的过期key数量
• evicted_keys：因内存不足被淘汰的key数量
• keyspace_hits/misses：缓存命中率

建议将这些指标纳入监控系统，当发现expired_keys增长缓慢而内存持续升高时，可能需要调整定期删除的频率或内存淘汰策略。

5.2 过期时间设置技巧

• 避免批量设置相同的过期时间：容易引发缓存雪崩
• 对热点数据采用"基础过期时间+随机偏移量"的策略：如设置过期时间为3600 + random(600)秒
• 对永不删除的配置类数据可以不设置过期时间，但要确保有更新机制

5.3 特殊场景处理方案

对于必须精确删除的场景，可以考虑以下方案：

1. 使用Redis模块实现自定义的精确删除逻辑
2. 在应用层维护一个优先队列，主动触发删除
3. 对于少量关键key，可以结合Lua脚本实现二级过期检查

在最近的一个物联网项目中，我们就在Lua脚本中增加了双重过期检查，即使Redis的定期删除有延迟，业务逻辑也能保证数据一致性。

6. Redis版本演进中的改进

从Redis 4.0开始，过期删除机制有了重要优化：

• 引入了lazyfree-lazy-expire配置项，可以将过期删除操作放到后台线程执行，减少对主线程的阻塞
• Redis 6.0的多线程IO模型中，过期删除仍然由主线程处理，但网络IO的并行化间接提高了删除效率

在升级到Redis 6.2后，我们观察到在相同负载下，主动删除的延迟降低了约15%，这对高吞吐量场景很有帮助。不过要注意，这些改进并没有改变过期删除的基本原理，只是提高了执行效率。