TTL / Expiration Lab
同一秒过期,数据库会看到什么?
把一批缓存设成相同 TTL,它们会在同一时刻失效并集中回源。给 TTL 加上随机抖动,相同数量的查询会被摊到一段时间里。
固定 TTL 峰值
8,000
次查询 / 秒
抖动后峰值
—
次查询 / 秒
峰值降低
—
相对固定 TTL
过期时间带宽
10:00
分:秒
过期时刻分布
固定 TTL
基础 TTL + 均匀随机抖动
固定 TTL 与随机抖动方案的 key 过期时间直方图。
固定 TTL:p50 —,p95 —
随机抖动:p50 —,p95 —
抖动改变的是“什么时候回源”,不是“要不要回源”
固定 TTL 会把本来可以分散完成的查询压进同一秒。抖动窗口越大,到期时刻越分散,峰值通常越低;代价是不同 key 的缓存寿命不再完全一致。生产中还应配合请求合并、互斥重建、限流与合理容量规划。
它不解决 Redis 整体不可用
节点宕机、网络隔离或全量缓存丢失时,所有请求仍可能一起打向数据库,需要单独设计熔断、降级、只读兜底与恢复预热。