Redis 过期键为什么还在：TTL、惰性删除与主动过期检查

线上缓存监控里经常会出现一个让人误判的现象：某个键已经过了 EXPIRE 设置的时间，抽样查询却还能看到它。先别急着把 Redis 判成“过期失效”。过期时间到了，Redis 会把键视为不可用；真正的物理删除可能由客户端访问触发，也可能由后台过期检查完成，所以“还看得到”和“还能正常读到”不是一回事。

排查过期键先用 TTL 看剩余时间，再用一次真实读取验证；不要只凭某个管理面板里的键数量判断过期机制失效。

EXPIRE 到点后，Redis 先改变了什么

下面这组命令足够复现问题：

SET session:1001 "ready"
EXPIRE session:1001 30
TTL session:1001

EXPIRE 写入的是过期时间戳。键还没有到期时，TTL 会返回剩余秒数；倒计时结束后，Redis 把它判定为过期对象。这个判断优先于“内存里是否已经完成回收”，因此一个过期键即使短时间仍占着内存，也不应该再被正常读取返回。图中的“访问命中”指客户端读取正好命中这个过期键，随后进入惰性删除路径。

观察时要避免把三个概念混在一起：过期时间是否写入、读取时是否被判为过期、内存对象何时完成释放。它们都和“键还在不在”有关，但不是同一个检查。

为什么一次访问会让过期键突然消失

Redis 处理客户端读取时，会检查目标键的过期时间。如果键已经过期，读取路径不会把旧值交给业务，而是将其视为不存在，并在这个过程中完成清理。这就是惰性删除：没有访问，就没有必要为每一个冷键单独安排一次即时删除；一旦访问，过期状态会被立刻暴露。

GET session:1001
TTL session:1001

如果第一次 GET 发生在过期时间之后，返回值应当是空值；随后再查 TTL，通常会看到 -2，表示键已经不存在。这里的 TTL 是很有用的验收信号：-1 是“键还在但没有过期时间”，-2 才是“键不存在”。

这条路径也解释了为什么业务日志里常见“刚查到，下一次就没了”。前一次可能只是管理工具看到了键的元数据，后一次真实访问触发了过期判断；两次观察本来就不是同一条读取路径。

后台主动过期检查如何清理没人访问的键

如果大量过期键永远没有客户端访问，只靠惰性删除就会留下无意义的内存占用。Redis 还会在后台进行主动过期检查：在过期键较多的数据库中采样键，发现过期对象就删除，并在达到本轮 CPU 预算后让出时间片。

可以把这个过程拆成四个正文里真实存在的节点：ACTIVE_EXPIRE_CYCLE 代表主动过期检查路径，采样键 是检查入口，删除过期键 是命中后的动作，CPU预算 是本轮主动清理的边界。它不是一次性扫描整个数据库，所以过期键数量不会在同一毫秒全部归零。

ACTIVE_EXPIRE_CYCLE
        -> 采样键
        -> 删除过期键
        -> CPU预算

因此，监控里看到短暂的过期键残留，不足以证明 Redis 没有执行过期。更值得关注的是内存是否持续上升、过期处理是否长期赶不上写入速度，以及业务读取是否在过期后仍拿到旧值。

用 TTL、GET 和内存指标把误判拆开

排查时建议固定一个键名，记录设置时间、TTL 返回值、真实读取结果和读取后的 TTL。如果每次读取都返回空值，只是管理视图仍显示数量，问题更可能在监控采样或刷新时机；如果真实业务仍拿到旧值，才需要继续核对是否读到了另一个 Redis 实例、是否使用了不同的键名，或者应用层缓存没有失效。

常见问题与边界

过期键会不会永远留在 Redis 内存里？

正常过期路径不会让它永久保留。访问会触发惰性删除，后台主动过期检查也会处理冷键；短时间残留与永久不清理不是一个结论。

为什么 TTL 返回 -1？

-1 表示键存在但没有关联过期时间。常见原因是后续写入命令覆盖了原键，或者设置过期的命令没有作用到实际写入的键名。

只看 DBSIZE 能判断过期是否正常吗？

不能。DBSIZE 是某个时刻的键数量，无法替代对固定键执行 TTL 和真实读取。要判断清理压力，还要结合内存和过期处理统计。

把“键还在”改成可验证的排查结论

Redis 的过期机制不是到点瞬间做一次全库清扫，而是把逻辑过期判断、访问触发清理和后台主动检查组合起来。下次遇到过期键残留，按 TTL、GET、读取后的 TTL 顺序记录证据，再观察内存趋势和过期处理压力，才能分清是观察时机、键名/实例错误，还是清理速度跟不上写入。