Redis 过期键为什么没有立刻消失：惰性删除、定期抽样与内存回收

给 Redis 键设置了 EXPIRE session:42 60，一分钟后用 SCAN 仍然偶尔能看到它，或者内存曲线没有马上下降，这并不代表过期时间失效。Redis 把“已经到期”和“已经从内存中清走”分成了两个时刻：访问时会顺手清理，后台也会抽样处理，但大值回收还可能继续占用一段资源。

判断过期是否正常，先用 TTL 看时间语义，再用 INFO memory 和 MEMORY USAGE 看回收结果；不要拿一次 SCAN 或瞬时内存读数直接下结论。

EXPIRE 的到期时刻不是删除事件

EXPIRE 写入的是一个过期时间点。它到点后，Redis 会把这个键视为不可用；但物理删除需要在访问路径或后台清理路径中发生。下面这组命令适合先建立一个小实验：

SET session:42 active
EXPIRE session:42 60
TTL session:42
MEMORY USAGE session:42

刚设置完时，TTL 应该返回接近 60 的整数。等待超过这个时间后再访问 GET session:42，结果应为空，随后再次查看 EXISTS session:42 会得到 0。读取动作本身可能触发惰性删除，所以“访问后消失”不能证明后台每秒都扫描到了它。

两条清理路径：访问触发与后台抽样

惰性删除适合处理真正被访问到的键。请求到达时，Redis 发现该键已经过期，就不再把旧值返回给客户端，并完成相应清理。它不会为无人访问的键反复付出检查成本；代价是大量无人访问的到期键可能暂时留在内存结构里。

后台路径会周期性抽取一部分带过期时间的键进行检查。抽样发现到期键后就清理，命中率较高时会继续处理一小段时间。它不是把整个键空间按顺序扫一遍，因此“过期一秒”和“已经完成物理删除”不能画等号。

用三组观察把问题拆开：

• 语义确认：用 TTL 或 PTTL 判断剩余时间；返回 -2 表示键不存在，返回 -1 表示没有过期时间。
• 路径确认：对已经到期的键做一次 GET 或 EXISTS，确认访问侧不会读到旧值。
• 容量确认：用 INFO memory 看整体分配，用 MEMORY USAGE key 找具体大值。

为什么大键消失了，used_memory 还没立刻降

删除一个小字符串通常很快，但删除大 Hash、List、Set 或 Sorted Set 需要处理更多内部对象。此时可以出现两个看似矛盾的现象：EXISTS big:key 已经是 0，INFO memory 的 used_memory 却还在高位；或者业务延迟在清理窗口出现抖动。

先不要马上调大后台回收强度。先用 MEMORY USAGE big:key 对照键类型和写入批次，再看 INFO memory 中的 mem_fragmentation_ratio。前者偏向对象本身大小，后者还受分配器碎片、其他键和进程保留内存影响。

一套不误判的排查顺序

1. 先对目标键执行 TTL key 或 PTTL key，记录返回值和采样时间。
2. 如果键已到期，执行一次 EXISTS key，验证读取路径不会返回旧值。
3. 用 INFO memory 每隔固定窗口记录 used_memory、used_memory_rss 和 mem_fragmentation_ratio。
4. 对可疑大值使用 MEMORY USAGE key，不要在生产环境随意对大集合执行全量成员读取。
5. 确认是持续性堆积后，再评估过期抽样强度和大值拆分方案，并保留修改前后的同窗口数据。

参数调整前先看三个边界

不要把 active-expire-effort 当成清理开关

它影响主动过期工作的投入程度，不会改变键的 TTL 语义，也不能替代大键治理。提高强度前要确认 CPU 余量和请求延迟。

不要用 SCAN 结果证明过期键一定还可读

SCAN 是增量遍历，结果允许重复，也不承诺一次遍历期间的稳定快照。即使扫描时看到了键，也要用业务读取命令和 TTL 单独确认。

不要把分配器保留空间当成 Redis 泄漏

used_memory 与 RSS 的变化不一定同步。对象释放后，分配器可能暂时保留页供后续复用，要结合 used_memory_rss、碎片率和多个时间窗口判断。

相关问题

TTL 到 0 时，客户端还能读到旧值吗？

正常读取不会把已到期键当作有效值返回。TTL 接近 0 只是观测时刻的整数显示，真正判断应以读取结果和返回状态为准。

为什么设置了 EXPIRE，键却没有按顺序消失？

后台采用抽样清理，访问路径又会触发惰性删除，所以不同键的物理清理时刻可能不同。

Redis 过期键很多时先改什么？

先确认是否有大值、突发写入或碎片问题，再用固定窗口比较清理前后的内存和延迟；不要只凭一个瞬时指标调参数。

把“过期”与“回收”分别验收

Redis 的过期机制优先保证访问语义，再通过惰性删除和后台抽样逐步回收对象。TTL 回答“它还是否有效”，EXISTS 回答“访问是否读到旧值”，INFO memory 和 MEMORY USAGE 才回答“内存是否真的释放”。把这四个观察点放在同一时间线上，通常就能避免把正常延迟清理误判成过期失效。