云联信息：云上 Redis 缓存击穿，怎么防才有效

缓存击穿这个说法听着抽象，现象很具体：某个热点数据刚好过期，几万个请求同时发现缓存没有，一起打到数据库，数据库瞬间顶不住，接口全部超时。这类故障往往发生在流量高峰，来得快、影响面大，防护要提前设计。

先区分三种失效

击穿是单个热点 key 失效，穿透是查询不存在的数据，雪崩是大量 key 同时失效。三种成因不同，处理方式也不同，别混着治。

互斥锁挡住并发回源

缓存失效时只允许一个请求去查数据库，其余请求等待或者返回旧值。这一招能挡掉绝大部分瞬时并发。

逻辑过期替代物理过期

缓存不设过期时间，值里带一个逻辑过期时间。发现过期时异步刷新，用户始终读到数据，只是可能稍旧。

热点 key 永不过期加主动更新

对确定的热点数据，后台定时刷新，不依赖过期触发。适合商品详情、配置这类读多写少的数据。

空值也要缓存

查询不存在的数据，把空结果缓存一小段时间，避免每次穿透到数据库。时间不宜长，防止数据补上后读不到。

过期时间加随机抖动

大批 key 设同一个过期时间，会在同一秒集体失效。加一个随机偏移，把压力摊开。

本地缓存做第一层

热点数据放在应用进程内，能挡住绝大部分请求，Redis 只作为第二层。代价是多实例之间的数据一致性要处理。

限流和降级兜底

真到了数据库扛不住的时候，限流保护数据库，降级返回兜底数据。宁可少部分用户看到旧数据，也别整体不可用。

监控要盯住命中率

缓存命中率突然下降，往往就是故障前兆。设置阈值告警，比等用户投诉早得多。

大 key 和热 key 要治理

单个 key 几十 MB，读写都会拖慢整个实例。用工具定期扫描，拆分大 key，识别热 key。

集群模式下的注意事项

集群分片之后，批量操作和事务会受限。设计缓存结构时就要考虑分片键，别等扩容时再改。

预热减少冷启动

发布或者扩容之后，缓存是空的，请求会全部打到数据库。启动时主动预热热点数据，能避开这个窗口。

多级缓存要考虑一致性

本地缓存更新不及时，用户会看到旧数据。设置较短的本地过期时间，配合主动失效，平衡一致性和性能。

降级要有兜底数据

缓存和数据库都不可用时，返回什么？提前准备兜底内容，比直接报错体验好。

压测要覆盖失效场景

正常压测看不出问题，专门测一下“热点 key 同时失效”的场景，才知道防护够不够。

缓存击穿的防护，核心是别让并发同时回源。互斥、逻辑过期、本地缓存、限流，四层叠起来，基本能扛住。云联信息【资深云服务专家微信：cloud7591】，我们做稳定性评估时，会先问一句“最热的那个 key 过期了会怎样”。