详解Redis缓存击穿、缓存穿透、缓存雪崩

一、缓存穿透（Cache Penetration）

1.1 问题描述

• 定义：查询数据库中根本不存在的数据，导致请求每次都绕过缓存直接访问数据库。

• 特点：

  • 恶意攻击常见手段（如请求id=-1或随机乱码）。

  • 缓存和数据库均无数据，导致无效查询压垮数据库。

1.2 原因

• 恶意攻击、业务逻辑漏洞（如参数校验缺失）。

1.3 解决方案

• 缓存空对象（Null Caching）

  • 对数据库查询结果为null的Key，缓存一个空值（如"NULL"），并设置较短过期时间（如30秒）。

  • 风险：可能缓存大量无效Key，需定期清理。

• 布隆过滤器（Bloom Filter）

  • 在缓存层前加布隆过滤器，快速判断Key是否存在：

    • 若过滤器返回不存在，直接拒绝请求。

    • 若返回存在，再查缓存/数据库。

  • 特点：存在一定误判率（可调整），但内存占用极低。

• 业务层校验

  • 对请求参数做合法性检查（如ID格式、范围限制）。

  • 接口限流、黑名单拦截恶意IP。

二、缓存击穿（Cache Breakdown）

2.1 问题描述

• 定义：某个热点Key突然过期时，大量并发请求同时绕过缓存直接访问数据库，导致数据库瞬时压力激增。

• 特点：

  • 针对单个高并发访问的Key（如热门商品、秒杀商品）。

  • 缓存失效瞬间被大量请求穿透。

2.2 原因

• 热点Key设置了相同的过期时间，到期后同时失效。

• 突发流量集中访问该Key（如热搜事件）。

2.3 解决方案

• 互斥锁（Mutex Lock）

  • 当缓存失效时，只允许一个线程重建缓存，其他线程等待。

• 使用本地缓存做缓冲

  • 在应用服务器本地使用本地缓存（如Guava Cache）来存储热点数据。当Redis缓存过期时，先从本地缓存获取数据，本地缓存也失效时再去数据库查询。本地缓存可以设置一个较短的过期时间，这样可以缓冲对数据库的压力。例如，本地缓存的过期时间可以设置为10分钟，当Redis缓存过期后，第一个请求线程会先从本地缓存获取数据，本地缓存也过期的话，它再去数据库查询并将数据更新到本地缓存和Redis缓存。

• 热点Key永不过期

  • 对极热点Key不设置过期时间，通过后台任务定时更新。

• 异步定时更新

  • 比如某一个热点key的过期时间是60分钟，那每59分钟就定时任务去更新这个热点key，并重新设置其过期时间

三、缓存雪崩（Cache Avalanche）

3.1 问题描述

• 定义：大量缓存Key同时过期或缓存服务宕机，导致所有请求涌向数据库，引发连锁故障。

• 特点：

  • 大规模Key失效（如缓存集群重启、批量Key过期）。

  • 数据库压力远超击穿（影响范围更广）。

3.2 原因

• 大量Key设置了相同的过期时间（如系统初始化时批量加载数据）。

• Redis集群宕机。

3.3 解决方案

• 分散过期时间

  • 对缓存Key的过期时间添加随机值（如基础时间 + 随机1~5分钟）。

    int expireTime = 3600 + ThreadLocalRandom.current().nextInt(0, 300); 

• 高可用缓存架构

  • Redis集群采用主从+哨兵（Sentinel） 或 集群模式（Cluster），避免单点故障。

  • 多级缓存：本地缓存（Caffeine） + 分布式缓存（Redis）。

• 服务熔断与降级

  • 当数据库压力过大时，启用熔断机制（如Hystrix），暂时拒绝请求，返回兜底数据。

  • 降级方案：返回默认值、静态页面等。

• 缓存预热（Warm Up）

  • 系统启动时提前加载热点数据到缓存。

  • 后台定时更新即将过期的Key。

四、三者的核心区别

问题	触发条件	影响范围	本质原因
缓存击穿	单个热点Key突然失效	单个Key的高并发请求	热点数据重建并发冲突
缓存穿透	查询不存在的数据	无关Key的重复请求	数据本身不存在
缓存雪崩	大量Key同时失效	大规模Key失效	过期时间集中/服务宕机

五、实战建议

• 击穿：优先用互斥锁或逻辑过期，适合秒杀场景。

• 穿透：布隆过滤器 + 空对象缓存，适合防恶意攻击。

• 雪崩：过期时间随机化 + 多级缓存，适合大促前的系统检查。

通过合理组合以上策略（如布隆过滤器防穿透 + 互斥锁防击穿 + 集群化防雪崩），可显著提升系统抗高并发能力。