缓存 TTL（Time To Live，生存时间），指的是缓存里的一份数据从写入那一刻起，过多久就自动作废，下次读取时必须回源，也就是回到数据库或后端服务重新取。
打个比方：TTL 就是冰箱里那盒牛奶的保质期。保质期设得太短，你就得天天跑超市；设得太长，又会喝到变质的。缓存也一样：TTL 长，命中率高、数据库轻松，但用户可能看到几小时前的旧数据；TTL 短，数据新鲜，但回源请求变多，数据库压力就大。所以 TTL 的关键是「这份数据最多能旧到什么程度」，而不是「哪个数值最优」。商品库存可能要几秒，一篇博客正文可能要几小时，中间的差别由业务决定。真要定得准，看得是官方文档和实际压测，别照搬别人的数字。
问题往往出在过期的那一瞬间。
假设首页热门配置的缓存 TTL 设成 60 秒，全站几十台服务器几乎在同一秒写入了这份缓存，于是 60 秒后它们也在同一秒一起过期。这一秒内涌进来的成千上万个请求全部未命中（cache miss），一起打到数据库。平时缓存帮你挡住了绝大部分流量，此刻却是几乎全量流量同时涌来，数据库很容易直接被压垮。这就是缓存击穿（cache stampede），也叫惊群效应（thundering herd）。
关键在于：数据库撑不住的往往不是平均流量，而是同一毫秒内涌来的流量。
随机抖动（jitter）就是解决办法：写入缓存时不要固定写 60 秒，而是写成 60 秒再加一个随机数，比如 0 到 6 秒之间。几十台机器的过期时刻因此被分散到这 6 秒里，压力也从一瞬间的高峰变成一段平缓的流量。改动几乎零成本，效果却很明显。
除了抖动，还有几件工具通常会和它一起用：
- 互斥锁或单飞（singleflight）：只放一个请求去回源，其余请求等它的结果；
- 逻辑过期 + 后台刷新（stale-while-revalidate）：先返回旧数据，同时异步更新；
- 热点 key 干脆不设过期，靠主动失效（cache invalidation）来更新。
| 机制 | 触发条件 | 解决的问题 |
|---|---|---|
| TTL 过期 | 时间到了 | 数据不要放太久 |
| 淘汰策略（如 LRU） | 内存满了 | 空间不够用 |
| 主动失效 | 数据被改动 | 一致性要求高 |
最后有个常见误区：TTL 只是保底措施，不是更新数据的主要手段。数据一旦被改动，就应该主动删除或更新对应缓存；TTL 只负责清理那些没被及时更新、已经过期的旧数据。指望用 TTL 保证一致性，就像指望靠保质期记住牛奶是哪天打开的。
对非技术岗位的人来说，这里有一条通用启发：当有人问「这个缓存设多久过期」，真正的答案通常是先看业务能容忍多旧的数据，再在此基础上加一点随机。整齐划一的过期时间看起来很干净，但在高并发下往往最容易出问题。