TTL / Expiration Lab

同一秒过期,数据库会看到什么?

把一批缓存设成相同 TTL,它们会在同一时刻失效并集中回源。给 TTL 加上随机抖动,相同数量的查询会被摊到一段时间里。

固定 TTL 峰值 8,000 次查询 / 秒
抖动后峰值 — 次查询 / 秒
峰值降低 — 相对固定 TTL
过期时间带宽 10:00 分:秒

过期时刻分布

固定 TTL 基础 TTL + 均匀随机抖动

固定 TTL 与随机抖动方案的 key 过期时间直方图。

固定 TTL:p50 —,p95 — 随机抖动:p50 —,p95 —

抖动改变的是“什么时候回源”,不是“要不要回源”

固定 TTL 会把本来可以分散完成的查询压进同一秒。抖动窗口越大,到期时刻越分散,峰值通常越低;代价是不同 key 的缓存寿命不再完全一致。生产中还应配合请求合并、互斥重建、限流与合理容量规划。

它不解决 Redis 整体不可用

节点宕机、网络隔离或全量缓存丢失时,所有请求仍可能一起打向数据库,需要单独设计熔断、降级、只读兜底与恢复预热。