Redis 过期键为什么没有按时删除：惰性删除、定期采样与内存观察

Redis 里的键到了过期时间，却没有在那一秒立刻从内存里消失，这个现象很常见。先别急着改 TTL：过期键会在被访问时触发惰性删除，也会由后台的主动过期流程抽样清理。判断问题的关键，是把“逻辑上已过期”和“物理内存尚未回收”分开观察。

先确认“过期”与“删除”不是一回事

给测试键设置一个很短的生命周期，然后在过期前后分别查看状态：

SET demo:expiry "v1" EX 5
TTL demo:expiry
sleep 6
TTL demo:expiry
EXISTS demo:expiry
GET demo:expiry

这里的 sleep 6 只是测试命令，不是生产处理方案。过期后，TTL 通常返回 -2，EXISTS 返回 0，GET 返回空值。Redis 在判断这个键时已经把它当作不存在，即使后台清理线程还没有遍历到它。

一次读取为什么会触发惰性删除

惰性删除的触发点是访问路径。客户端请求 GET demo:expiry 时，Redis 先判断过期时间；如果已经过期，就返回缓存未命中，并清理这个键。对业务来说，结果是“读不到”；对内存来说，清理动作也在这个访问过程中发生。

这个机制能避免 Redis 为每一个键都维护精确的定时器，但也意味着只观察某个时刻的内存快照，不能反推出所有过期键都已经完成物理回收。尤其是写入后几乎不再访问的大键，更容易等待主动过期流程。

主动过期抽样如何处理无人访问的键

后台主动过期会从带有过期时间的键中抽样，发现已过期的成员就删除，再继续处理。它的目标是控制过期清理的 CPU 成本，而不是在每个 TTL 到点的瞬间完成全量扫描。键数量、过期键比例和实例负载都会影响观察到的清理节奏。

可以用一个小批次做对照实验：

for i in $(seq 1 100); do
  redis-cli SET "demo:expiry:$i" "$i" EX 10 >/dev/null
done
redis-cli INFO keyspace
redis-cli INFO memory

不要把某次 INFO memory 的数值当成精确的过期键计数。它更适合观察趋势：过期批次结束后，used_memory 是否回落，碎片率是否异常，以及业务流量是否同时发生变化。

哪些情况值得按安全风险处理

过期延迟本身通常是实现机制，但下面几类现象需要提高优先级：

把验证命令写进审计清单

排查单个键时，至少保留键名、设置命令、观察时间、TTL、EXISTS 和实际读取结果。排查实例时，再记录 INFO memory 的连续样本和业务请求量。MEMORY USAGE key 可以帮助定位大键，但它只说明当前键的占用，不能直接统计全部待清理对象。

TTL demo:expiry
EXISTS demo:expiry
MEMORY USAGE demo:expiry
INFO memory

如果键已经过期，最后一条 MEMORY USAGE 可能得到空结果，这是正常的。这里别急着用“重启 Redis”验证：重启会改变缓存可用性和故障面，无法证明过期清理逻辑是否正确。

常见问题

Redis 过期键会在 TTL 变成 0 时立刻删除吗？

不保证在同一秒完成物理删除。TTL 到期表示键已经不可用，物理回收可能由访问触发，也可能稍后由主动过期流程完成。

为什么 EXISTS 已经是 0，内存还没有明显下降？

单键已经不再可读，但其他冷键可能尚未被抽样；另外内存分配器也可能暂时保留已申请的空间。应连续看实例指标，而不是只看一次快照。

能不能定期扫描全库删除过期键？

通常不建议把全库扫描当作常规方案。先检查写入节奏、键体积、过期时间分布和实例负载，必要时拆分大键与热点流量。

过期后还能读到旧值，应该先查什么？

先确认请求连的是哪台 Redis，再检查应用本地缓存、代理层和副本读取。当前实例的 TTL 与 GET 结果只能证明这一跳的状态。

结语：把可见延迟和真实风险分开

Redis 过期机制用惰性删除和主动抽样换取了可控的运行成本，所以“没有立即看到内存下降”并不自动等于故障。先用 TTL、EXISTS 验证业务可见性，再用 INFO memory、MEMORY USAGE 和连续样本判断实例压力，处理动作才不会误伤在线缓存。