Redis过期数据删除策略解析

Redis 的 volatile-ttl 内存淘汰策略是唯一专为“优先删除最接近过期的键”而设计的机制：它仅作用于已设置过期时间（ttl > 0）的键，在内存不足触发写入时，每次精准挑选剩余生存时间最短的一个键进行淘汰，而非批量清理或主动扫描；其核心优势在于目标明确、轻量高效，但需注意它依赖采样近似比较、不保证全量排序，且严格过滤 ttl ≤ 0 的键（如永久键、已逻辑过期键或未设过期时间的键），实际使用中务必通过配置验证、INFO 指标观测和 TTL 值抽样来确认行为符合预期——理解这些细节，才能真正让 Redis 在高并发场景下智能、可靠地释放即将失效的内存。

volatile-ttl 是唯一正解

Redis 本身不提供“按剩余过期时间排序后淘汰”的通用策略，但 volatile-ttl 就是专为这个场景设计的：它只在设置了过期时间的键中，挑 ttl 值最小（即最接近到期） 的那个淘汰。不是“即将到期的多个”，而是每次只选一个——但它的行为逻辑就是“越快过期，越优先被踢”。

为什么 volatile-ttl 不等于“批量清理临期键”

很多人误以为开了 volatile-ttl 就会自动扫一遍所有快过期的 key 并清掉一批。其实不是：volatile-ttl 是内存淘汰策略，只在 写入新数据触发内存不足时才启动，且每次只淘汰一个 key（或少量，取决于实现细节），目标是腾出足够空间让当前命令成功执行。它不会主动扫描、也不会提前“防患于未然”。

• 它不干预惰性删除和定期删除对过期键的常规清理
• 它不管没设过期时间的 key（allkeys-* 系列才管）
• 它不保证“绝对最短 ttl”，因为 Redis 用的是采样 + 近似比较，不是全量排序

配置和验证要一起做

光改配置不够，得确认生效且符合预期：

• 修改 redis.conf 中的 maxmemory-policy volatile-ttl，重启或用 CONFIG SET maxmemory-policy volatile-ttl
• 用 INFO memory 查看 maxmemory_policy 字段是否已更新
• 用 INFO stats 观察 evicted_keys 是否增长，并配合 redis-cli --scan --pattern "*" + TTL 手动抽样比对被删 key 的 ttl 值是否确实偏小

注意：如果业务里大量 key 的 EXPIRE 时间设得非常集中（比如统一设了 60s 后过期），volatile-ttl 在高并发写入时可能连续淘汰一批 ttl≈0 的 key，看起来像“批量清理”，但这只是巧合，不是机制保障。

容易踩的坑：ttl 为 -1 或 -2 的 key 会被跳过

volatile-ttl 只处理 ttl > 0 的键。如果某个 key 被 PERSIST 过、或原本就没设过期时间、或已被定期删除/惰性删除判定为过期（此时 TTL 返回 -2），它就直接从候选池里剔除了——哪怕你刚给它 EXPIRE 但还没来得及刷新状态，也可能被漏掉。

更隐蔽的是：Redis 的 ttl 命令返回值含义：

• -1：key 存在但没过期时间
• -2：key 不存在 或 已逻辑过期（但尚未物理删除）
• >0：剩余秒数，这才是 volatile-ttl 真正比较的对象

所以如果你发现某些“明明快到期”的 key 没被优先淘汰，先 TTL keyname 看一眼返回值——不是所有“快到期”都算数。

本篇关于《Redis过期数据删除策略解析》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于数据库的相关知识，请关注golang学习网公众号！