TTL 设计原则
TTL 既是缓存的兜底机制，也是治理工具：没有过期时间的缓存键迟早会变成内存事故。设计原则是「热点短、冷数据长、同类数据加随机抖动」，同时明确哪些键允许豁免过期（例如需要手动刷新的版本号或全量字典），豁免项必须有清单和责任人，否则几年后没人说得清哪些键可以永不过期。
基本信息
| 原则 | 所有缓存键都必须有 TTL，或由业务显式豁免 |
|---|---|
| 抖动 | 同批数据的过期时间加随机量，避免集中到期 |
| 更新 | 数据变更时主动删除缓存，不依赖自然过期 |
| 审计 | 定期抽样找出没有 TTL 的键 |
| 监控 | 关注过期键数与淘汰键数，异常升高要查原因 |
典型使用场景
- 新业务上线前的缓存设计评审
- 同批数据设置相同 TTL 后出现集中到期与回源风暴
- 活动数据在整点集中过期造成数据库压力陡增
- 内存告警后清查没有过期时间的键
- 把「永久缓存」平滑改造成带 TTL 的策略
分层 TTL 示例
分层 TTL 示例
SET cfg:site init EX 600 # 配置类：10 分钟，变更少
SET user:1001 profile EX 300 # 会话与资料：5 分钟
SET hot:rank top EX 30 # 热榜：30 秒，可容忍略旧
SET promo:banner v1 EX 60 # 活动：1 分钟
TTL user:1001 # 查看剩余时间，-1 表示永不过期
# 加随机抖动：实际 TTL = 基础值 ± 20%
# 例如基础 300 秒，就随机取 240 到 360 秒之间的值场景与建议 TTL
| 数据场景 | 建议 TTL | 理由 |
|---|---|---|
| 配置与开关 | 5 到 30 分钟 | 变更少，可以容忍旧值 |
| 用户资料与会话 | 1 到 10 分钟 | 变更中等，容忍度中等 |
| 热榜与排行 | 10 到 60 秒 | 用户对新鲜度敏感 |
| 活动与秒杀信息 | 30 到 60 秒 | 需要较快生效但可承受轻微旧值 |
| 字典与枚举 | 较长或豁免 | 数据稳定，但必须有更新通道 |
到期风暴的根源是「同一批数据在同一秒过期」：给 TTL 叠加随机量，例如基础值上下浮动 20%，就能把过期时间摊开，避免大量请求同时回源数据库。
审计无 TTL 的键可以抽样执行 TTL 命令，或统计 INFO keyspace 中 keys 与 expires 的差值；差值长期很大，说明存在大量永不过期的键。
批量设置过期时间时要格外小心：一次给百万键设置相同的 TTL，等价于人为安排了一场雪崩，务必加入随机抖动并分批执行。