关于Redis过期键的三个技术疑问：比例设定与算法选择

官方文档「How Redis expires keys」核心内容翻译 #

Redis通过两种核心策略处理过期键：

1. 被动删除：当客户端访问某个键时，Redis会先检查该键是否过期，若已过期则立即删除。
2. 主动周期性删除（概率式）：Redis会定期执行以下操作：
   • 随机选取若干带过期时间的键
   • 删除其中已过期的键
   • 如果过期键占采样总数的比例超过25%，重复执行上述步骤
     另外，当Redis内存达到maxmemory限制时，触发的内存淘汰策略也会优先处理过期键。

1. 为何Redis的最大过期键清理量设定为每秒最大写入键数量的1/4？ #

这是为了平衡过期键清理效率和服务性能开销。Redis是单线程模型，清理过期键会占用主线程的CPU时间。如果每秒清理的过期键过多，正常读写请求的处理时间就会被挤压，导致服务延迟上升。

设定为每秒最大写入量的1/4是经过生产环境验证的折中阈值：既能避免过期键大量堆积，又不会让清理操作成为性能瓶颈。这个比例卡在“清理足够多过期键”和“不影响核心服务”之间，防止过度清理拖垮主线程。

2. Redis采用基于概率的周期性删除策略，为何设定采样中过期键占比超过1/4时要继续清理？你提到的“总内存1/4”其实是误解 #

首先纠正：这个1/4不是全局过期键占总内存的上限，而是采样清理时的触发阈值——当随机采样的键里，过期键占比超过25%，说明当前过期键堆积情况比较严重，需要继续采样清理；如果低于这个比例，说明过期键占比在可接受范围内，就停止清理，避免浪费CPU资源。

这种设定是动态调整清理强度的逻辑：过期键多就多清，少就少清，既不会让过期键无限堆积，又能避免无意义的CPU消耗，适配不同业务场景下的过期键数量波动。

3. 为何不采用按过期时间排序的删除方式？这种方式是否比概率方式更优？ #

按过期时间排序（比如用有序集合存所有带过期时间的键，按时间戳排序）看起来更精准，但存在两个致命问题：

• 性能开销极高：每次新增带过期时间的键都要插入有序集合，每次清理都要从有序集合头部取数据，这类操作的复杂度是O(logN)，远高于普通键操作的O(1)，在高并发场景下会大幅拖慢Redis的整体性能。
• 额外内存占用大：需要维护一个独立的有序集合来存储所有带过期时间的键，这会额外占用不少内存，对于内存敏感的Redis来说完全不可接受。

而概率式删除策略的优势就是轻量高效：不需要额外的数据结构，采样和清理操作对主线程的影响极小。所谓“不够可靠”的顾虑其实不成立——结合被动删除（访问时清理）和内存淘汰策略，过期键最终都会被清理，只是清理时机有延迟而已，这在绝大多数业务场景下都是可接受的。

内容的提问来源于stack exchange，提问作者feilong gao