Redis Key 过期时间应该如何设计？随机过期有什么作用？
简化版
Redis Key 的过期时间要按业务时效、数据热度和重建成本设计，不能所有缓存都写同一个 TTL。随机过期的作用是打散同一时刻大量 key 失效，降低缓存击穿或雪崩风险。
详细版
TTL 不是随手填一个数字。用户资料、商品详情、榜单、配置、验证码、分布式锁这些场景的过期目标不同：有的追求新鲜度，有的追求削峰，有的追求安全兜底。
工程上常见策略包括：基础 TTL、随机抖动、热点 key 续期、逻辑过期、永不过期加主动删除、短 TTL 配合缓存预热。随机过期通常写成“基础时间 + 随机偏移”，例如 3600 + rand(0, 600) 秒。
但随机过期不能替代一致性方案。缓存和数据库的写入顺序、删除策略、消息补偿、重试和监控仍要单独设计。
完整版教学
一、TTL 解决的不是一个问题
很多新人把 TTL 理解成“缓存多久自动删”，但在工程里它同时承担多个目标：控制脏数据时间、释放内存、防止旧缓存永久存在、削平集中失效风险。
例如商品价格缓存 5 分钟可能可接受，验证码 5 分钟是安全边界，分布式锁 30 秒是防死锁兜底。这些 TTL 背后的业务语义完全不同。
所以面试时要先讲原则：TTL 来自业务容忍度和系统成本，而不是统一配置。
二、为什么同一 TTL 会制造风险
假设秒杀活动在 10:00 统一预热了 100 万个商品缓存，TTL 都是 3600 秒。到 11:00 左右，这批 key 会集中失效，大量请求同时打到数据库。
随机过期就是给基础 TTL 加抖动，把失效点从一个尖峰摊开成一段时间。比如：
ttl = base + random(0, jitter)
base = 3600 秒
jitter = 600 秒
实际过期时间分布在 3600~4200 秒如果 100 万个 key 均匀分布在 600 秒内失效，平均每秒约 1667 个；如果集中在 1 秒失效，数据库瞬时压力会完全不同。
三、不同业务的 TTL 设计方式
TTL 要分场景，不要套模板。
| 场景 | 推荐思路 | 风险重点 |
|---|---|---|
| 商品详情 | 中等 TTL + 随机抖动 | 脏读和集中失效 |
| 首页榜单 | 短 TTL 或定时刷新 | 重建成本高 |
| 验证码 | 严格短 TTL | 安全边界 |
| 分布式锁 | 短 TTL + 续期谨慎 | 误释放和死锁 |
| 配置缓存 | 长 TTL + 主动失效 | 变更传播 |
这个表能体现你不是只会背“加随机数”，而是知道 TTL 和业务含义绑定。
四、随机过期和逻辑过期的区别
随机过期是物理 TTL 到点删除或淘汰；逻辑过期是 value 里放一个 expireAt，Redis key 本身可以不过期或设置更长兜底 TTL。
逻辑过期常用于热点缓存重建。请求发现逻辑过期后，先返回旧值，再由后台线程异步重建，避免大量请求同时阻塞在数据库查询上。
示意 value：
{
"data": {"id": 1001, "price": 99},
"expireAt": "2026-07-30T11:30:00+08:00"
}这种方式牺牲一点实时性，换取热点读的稳定性。
五、TTL 还要配合内存治理
Redis 内存有限，TTL 设计也会影响内存曲线。如果大量 key 没有过期时间，内存只能靠淘汰策略或人工清理；如果 TTL 太长，旧数据堆积会挤压热点数据。
可以做一个简单估算：平均 value 2KB，缓存 200 万条，就是约 4GB 裸数据；再加对象元数据、字典、碎片和复制缓冲，实例实际占用可能明显更高。
因此 TTL 不是只影响“准不准”，还影响 Redis 成本、淘汰概率和延迟稳定性。
六、常见误区与追问
- 误区：所有缓存统一设置 30 分钟最简单。 不同数据的新鲜度、重建成本和安全要求不同，统一 TTL 会制造隐藏风险。
- 误区：随机过期能解决所有雪崩。 它只能打散自然过期，不能解决 Redis 故障、数据库慢查询或热点重建问题。
- 误区：TTL 越短数据越一致。 TTL 短会增加回源压力，反而可能拖垮数据库。
- 追问：热点 key 适合直接物理过期吗？ 高并发热点通常要考虑逻辑过期、互斥重建或后台刷新。
- 追问：没有 TTL 的 key 一定错吗？ 不一定，配置、字典类数据可长驻，但要有主动更新、容量评估和监控。
七、加强记忆
记忆钩子：TTL 不是闹钟，而是“新鲜度、容量、削峰和兜底”的综合设计；随机过期只是把一排闹钟改成错峰响。
回答时可以按“业务容忍度定基础 TTL，随机抖动防集中失效，热点用逻辑过期，容量靠估算和监控”来组织。这样既能覆盖缓存雪崩，也能落到 Redis 运维和业务一致性。