缓存击穿是单个热点key过期瞬间被并发打穿，表现为高并发请求同时穿透至数据库；缓存雪崩是大批量key集中失效导致DB压力骤增；二者均不适用布隆过滤器或空值缓存。
缓存击穿是单个热点key过期瞬间被并发打穿
现象是：某个高频访问的 key（比如秒杀商品ID、热搜词条）恰好在过期时刻，大量请求同时发现缓存 miss，全部涌向数据库，造成瞬时 DB 压力尖峰。关键点在于「一个 key」+「过期时间点」+「高并发」。
应对重点是保护这个 key 的加载过程不被并发穿透：
- 对这个
key不设过期时间，或用定时任务提前刷新（如每 59 分钟 reload 一次） - 加互斥锁：用
SETNX或Redisson的分布式锁，确保同一时刻只有一个线程查 DB 并回写缓存 - 避免锁粒度太粗——只锁该
key，不要锁整个业务模块 - 注意锁超时时间必须小于业务查询 DB 的最大耗时，否则可能死锁或重复加载
缓存雪崩是大批量不同key在同一时段集中失效
现象是：大量 key（比如首页推荐、用户画像、配置项）设置了相同或相近的过期时间（如统一设为 2 小时），在某个整点批量过期，导致大量请求同时穿透到 DB，DB 连接池被打满甚至宕机。关键点在于「多个 key」+「时间集中」+「无差别穿透」。
应对核心是打散失效节奏、增加系统容错能力：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 设置过期时间时加随机偏移，例如基础 TTL 是 7200 秒，再叠加
0~600秒的随机值 - 对核心数据启用双缓存机制：
cacheA（带 TTL）+cacheB（永不过期），cacheA失效后先读cacheB，再异步更新两者 - 服务降级：非核心数据在缓存失效时直接返回默认值或空，不查 DB
- 熔断限流：当 DB 耗时突增或错误率超标时，自动拦截后续缓存查询请求，避免雪上加霜
布隆过滤器和空值缓存对击穿/雪崩基本无效
布隆过滤器解决的是「缓存穿透」——即查一个根本不存在的 key；而击穿和雪崩的前提是 key 真实存在、只是缓存暂时不可用。往缓存里塞 null 值对击穿没意义（它本来就有值），对雪崩反而有害（空值也占内存、也参与批量过期）。
容易踩的坑：
- 误把所有缓存问题都套用「缓存空值」方案，结果雪崩时缓存里堆满短过期的
null，加剧内存压力和淘汰抖动 - 给所有 key 统一加随机过期时间，但没考虑业务语义——比如用户登录态必须严格 30 分钟过期，硬加随机会导致安全或体验问题
- 用本地锁（
synchronized）处理分布式环境下的击穿，实际完全不起作用
真正要盯住的是过期策略与监控联动
击穿和雪崩本质上都是「缓存生命周期管理失控」的表现。比写一堆 if-else 更关键的是：
- 在 Redis 客户端层统一封装 TTL 设置逻辑，强制加入随机因子，而不是靠开发人员手写
set(key, val, 7200 + random(600)) - 接入 Redis 监控，重点关注
expired_keys指标突增、evicted_keys异常升高、以及缓存命中率（keyspace_hits / (keyspace_hits + keyspace_misses)）断崖下跌 - 命中率连续 3 分钟低于 85% 时，自动触发告警并 dump 当前 TOP 100 过期中的 key，人工判断是否出现雪崩苗头
最常被忽略的一点：缓存过期不是越长越好，也不是越随机越好；它必须和业务更新频率、数据一致性要求、下游 DB 承载力做联合建模。没有银弹，只有权衡。
