缓存穿透-击穿-雪崩#

现象：查询一个不存在的 key，缓存中没有，每次都直接打到 DB
场景：恶意攻击（大量查询 id=-1 等不存在的数据）
危险：DB 被大量无效查询压垮

解决方案：
  1. 缓存空值：查询结果为空时，也在缓存中写入 null（短过期时间如 5min）
     缺点：可能缓存大量无效 key
  
  2. 布隆过滤器（推荐）：
     在请求到达缓存前，先用布隆过滤器判断 key 是否可能存在
     不存在 → 直接返回，不查 DB 也不查缓存
     缺点：有误判率（误判为存在的占少数），需要维护数据同步

现象：某个热点 key 突然过期，大量并发请求同时打到 DB
场景：秒杀商品详情、热门文章的缓存刚好过期

解决方案：
  1. 互斥锁（Mutex）：
     缓存失效时，只让一个线程查 DB 并重建缓存
     其他线程等待（或先返回旧数据）
     缺点：等待期间性能下降
  
  2. 逻辑过期（Logical Expiration）：
     key 永不真正过期，但在 value 中存储过期时间戳
     发现逻辑过期 → 异步线程重建缓存，同时返回旧数据（不阻塞）
     优点：不阻塞请求；缺点：短暂返回旧数据（最终一致）

现象：大量缓存 key 同时过期，或 Redis 实例宕机，流量全部打到 DB
场景：大量 key 设置了相同的过期时间

解决方案：
  1. 过期时间随机化：在基础过期时间上加随机偏移（如 TTL + random(0, 300s)）
  2. Redis 集群高可用：部署主从+哨兵或 Redis Cluster，避免单点故障
  3. 限流 + 降级：DB 前加限流，DB 承载不住时返回降级数据
  4. 本地缓存（多级缓存）：Redis 宕机时，本地缓存（Caffeine）提供兜底

现象：系统刚启动 / 大促开始时缓存是空的，瞬时流量全部打到 DB（冷启动雪崩）
解决方案：
  1. 启动时主动加载：项目启动后用定时任务/CommandLineRunner 把热点数据写入缓存
  2. 大促前手动刷：活动开始前用脚本预先把秒杀商品、热门榜单灌入 Redis
  3. 异步预热 + 错峰 TTL：预热时给不同 key 设随机过期时间，避免预热后又集体过期
关键：预热是"雪崩/击穿的事前预防"，把第一波流量挡在缓存层

现象：Redis 故障或 DB 扛不住时，需要保证系统不彻底崩溃（可用性优先）
解决方案：
  1. 兜底数据：返回默认值/旧数据/静态页（如"商品详情暂不可用"）
  2. 熔断限流：Sentinel/Hystrix 检测到 DB 压力过大时直接拒绝部分请求，返回降级结果
  3. 多级缓存兜底：Redis 挂了走本地缓存（Caffeine），本地也没有再返回默认值
  4. 读写分离降级：只保留核心读路径，关闭非核心的写/统计功能
关键：降级是"故障发生时的事中兜底"，宁可返回旧/兜底数据也不让请求压垮 DB