很多人以为给 key 设置 TTL，就像给它挂了一个精准闹钟：时间一到，Redis 立刻删除。真实情况更节制，也更工程化。
Redis 不会为每个 key 创建定时器。它会在访问时做惰性检查，也会通过 serverCron 定期抽样清理过期 key。这套机制平衡的是内存回收和 CPU 消耗。
先把机制边界说清楚
这一篇讨论 key 过期的内部策略，不讨论业务缓存是否应该过期。TTL 是缓存治理工具，但不是精准调度系统。
整体路径
上面这张图先把主线铺开：惰性删除负责访问时纠正，定期删除负责后台回收。读 Redis 这类系统，最重要的是别只停在命令接口，要继续追问它在内存里是什么形状、在主线程上走多远、失败时会留下什么状态。
底层机制
- 过期时间单独保存在 expires 字典里，和主 keyspace 分离。
- 惰性删除发生在访问 key 时，发现过期就删除并返回不存在。
- 定期删除按周期抽样检查，尽量在 CPU 和内存之间取得平衡。
- 过期 key 对持久化和复制也有传播规则，不是每个节点各删各的。
这些机制放在一起看，就能把「这个命令能不能用」改成「这个命令在当前数据规模下还便不便宜」。Redis 的很多坑，不是命令本身错了，而是数据规模和访问方式已经越过了它的舒适区。
取舍与边界
删除太积极会消耗 CPU，删除太懒会占内存。Redis 选择的是近似及时，而不是绝对准时。
典型问题：用机制化例子排查
- 大量 key 不要设置同一秒过期，TTL 加随机抖动。
- 不要依赖 Redis TTL 做精确任务调度，到期时间只能近似。
- 缓存雪崩排查时看 key 的过期分布，而不是只看数据库 QPS。
- 过期后重建要加互斥或逻辑过期，避免热点同时穿透到 DB。
收束：一句判断
TTL 解决的是生命周期，不是实时调度。
关于十三Tech
我是十三，All in AI Agent 方向的架构师，专注 AI 工程实践。
我相信 AI 是程序员的最佳搭档，也希望帮助每一位开发者更好地驾驭 AI。
如果你想继续跟完这套「图解 Redis」，欢迎关注公众号 「十三Tech」。后续会继续按数据结构、底层机制、持久化、高可用和实战排查这条线更新。
