Redis 过期键为什么没有按时删除：惰性删除、定期扫描与通知验证

缓存服务监控里偶尔会碰到一批明明已经过期，却还能在扫描结果里查到的 key，第一反应往往是 EXPIRE 没设置成功。实际排查时你会发现，Redis 的过期时间判定和删除动作根本不是同一个瞬间：key 可能在访问时才被惰性删除，也可能留着等后台定期扫描；TTL 查到的剩余时间，也不能直接当成内存占用已经清零。

现场症状：TTL 到期了，内存里的 key 还在

假设业务给 cache:coupon:8842 设置了 60 秒有效期。60 秒后用监控脚本统计 key 数量，发现它还出现在匹配结果里；但业务接口读取同一个 key 时已经拿到空值。这两个现象并不矛盾。

Redis 的过期 key 在逻辑上已经失效，读取时会先检查过期时间，失效就返回空并顺便删除。没有被访问到的 key，则可能暂时留在内部字典里，等定期任务抽样处理。这里先别急着改配置，先确认你测的是“还能不能读”，还是“物理上是否已经回收”。

为什么过期不会在同一秒完成删除

Redis 同时使用两条路径处理过期键。第一条是惰性过期：客户端访问 key 时，Redis 发现时间戳已过期，就让这次访问返回不存在，并删除该 key。第二条是主动过期：后台周期性抽样检查带有过期时间的 key，发现失效项后删除。

主动过期不是一次遍历所有 key。全量扫描会让 Redis 在 key 很多时卡住，所以系统用有限样本和时间预算换取平滑性。当大量 key 在同一秒过期，或者带过期时间的 key 占比很低时，清理完成时间自然会拉长。

一次故障排查应该按什么顺序走

先用 TTL 判断时间是否真的写入

SET cache:coupon:8842 "used" EX 60
TTL cache:coupon:8842
PTTL cache:coupon:8842

返回正数，说明 key 存在且仍有剩余时间；返回 -1，说明 key 存在但没有过期时间；返回 -2，说明 key 已不存在。若刚写入就返回 -1，应回到写入代码检查是否有后续 SET 覆盖了过期时间，而不是先怀疑 Redis 清理慢。

再把“还能读到”与“扫描列表里出现”分开

不要用 KEYS 作为生产验证工具。可以在低流量测试实例里观察固定 key 的读取结果，在生产则用业务命中率、采样查询和 Redis INFO 统计交叉判断：

INFO stats
INFO memory

expired_keys 是累计过期删除数，适合看趋势，不是当前残留数量。把它放进监控后，重点看单位时间增量；如果写入量稳定而增量长期为零，才值得继续检查写入链路、实例负载和过期策略。

集中到期时，真正的触发条件是什么

常见触发条件有三类。第一类是批量预热：发布时一次性写入数百万个相同 TTL 的 key，到了整点就形成过期峰值。第二类是过期 key 比例不高，主动扫描需要多轮抽样才碰到它们。第三类是实例本身正忙于处理大请求、持久化或网络写入，过期清理可用的 CPU 时间变少。

Redis 的 hz 和 active-expire-effort 可以影响后台任务的节奏，但它们不是“到期立即删除”开关。调参前先确认延迟预算：清理更积极会消耗更多 CPU，可能把缓存过期问题换成请求延迟问题。更稳妥的做法是把 TTL 加一点随机抖动，让批量 key 不要在同一秒同时失效。

修复动作：先错开到期，再决定是否调参

如果问题来自批量写入，可以在应用侧把有效期写成“基础 TTL 加随机秒数”，例如基础 300 秒、随机 0 到 30 秒。随机范围不宜大到改变业务语义，目标只是打散扫描压力。

base_ttl=300
jitter=0..30
final_ttl=base_ttl+jitter

如果是缓存一致性要求较高的场景，不要用“过期通知”作为唯一删除依据。开启 keyspace notification 后，事件是异步发布的，通知丢失、订阅者重启或网络拥塞都可能让下游漏掉事件。它适合做观测和辅助清理，关键数据仍要靠读时校验和可重放的补偿任务。

生产复查：用三个信号确认修复有效

1. 在写入链路记录带 TTL 的 key 类型和有效期范围，确认没有出现大量 -1。
2. 按分钟观察 expired_keys 增量、命中率、内存使用和实例 CPU，确认没有把清理压力推给请求线程。
3. 对一小批测试 key 记录写入时间、TTL、读取结果和删除通知，验证实际链路，而不是只看单次命令。

验收时还要看碎片率。过期对象被删除后，操作系统看到的 RSS 不一定立即同步下降，内存分配器和碎片整理会影响回收曲线。只要逻辑读取已经失效、expired_keys 持续增长、内存趋势符合负载变化，就不应该把 RSS 的短暂不降误判成过期失败。

常见问题：过期键排查里的几个误区

TTL 到 0 时，key 是否一定已经不存在？

不应把显示值当成原子时刻。TTL 是查询瞬间的近似结果，下一次访问可能已经返回 -2；业务判断应以实际读取结果为准。

打开过期通知后，能不能用它驱动订单状态变更？

不建议。通知适合监控、缓存补偿和低风险联动；订单、库存等关键状态要有持久化记录和可重试的业务任务。

调大 active-expire-effort 就能解决所有残留吗？

不能。如果根因是写入时根本没有设置 TTL，调参不会改变结果；如果根因是集中到期，打散写入时间往往比盲目加大后台预算更稳。

总结：把“过期”和“删除”当成两件事验证

Redis 过期键没有按整点从内存里消失，并不等于过期机制失效。先用 TTL 和读结果确认逻辑有效期，再用 expired_keys、CPU、内存碎片和通知链路判断物理清理进度。批量缓存优先加 TTL 抖动，生产调参必须配合延迟与内存指标复查，这样才能把一次偶发残留变成可解释、可验收的运维规则。