---

在如今的开发中，使用缓存中间件 Redis 已经成为一项很广泛的技术，Redis 的高性能大大优化了我们的服务器性能，缓解了在高并发的情况下服务器的压力。它基于缓存的形式，在内存中保存数据，减少对磁盘的 IO 操作。然而尽管 Redis 有着很多的优点，但仍然有三朵乌云漂浮在 Redis 的上空：穿透，击穿，雪崩。

缓存穿透

什么是缓存穿透？

请求的数据既不在缓存中，也不在数据库中（如恶意攻击、非法ID查询）。

缓存穿透说简单点就是大量请求的 key 根本不存在于缓存中，导致请求直接到了数据库上，根本没有经过缓存这一层。举个例子：某个黑客故意制造我们缓存中不存在的 key 发起大量请求，导致大量请求落到数据库。

缓存穿透情况的处理流程是怎样的？

用户的请求最终都要跑到数据库查询一遍。

缓存穿透的解决办法

最基本的就是首先做好参数校验，一些不合法的参数请求直接抛出异常信息返回给客户端。比如查询的数据库 id 不能小于 0、传入的邮箱格式不对的时候直接返回错误消息给客户端等等。

缓存无效 key

如果缓存和数据库都查不到某个 key 的数据就写一个到 Redis 中去并 设置过期时间，具体命令如下： SET key value EX 10086 。这种方式 可以解决请求的 key 变化不频繁的情况，如果黑客恶意攻击，每次构建不同的请求 key，会导致 Redis 中缓存大量无效的 key 。很明显，这种方案并不能从根本上解决此问题。如果非要用这种方式来解决穿透问题的话，尽量将无效的 key 的过期时间设置短一点比如 1 分钟。

另外，这里多说一嘴，一般情况下我们是这样设计 key 的： 表名:列名:主键名:主键值 。

如果用 Java 代码展示的话，差不多是下面这样的：

public Object getObjectInclNullById(Integer id) {
    // 从缓存中获取数据
    Object cacheValue = cache.get(id);
    // 缓存为空
    if (cacheValue == null) {
        // 从数据库中获取
        Object storageValue = storage.get(key);
        // 缓存空对象
        cache.set(key, storageValue);
        // 如果存储数据为空，需要设置一个过期时间(300秒)
        if (storageValue == null) {
            // 必须设置过期时间，否则有被攻击的风险
            cache.expire(key, 60 * 5);
        }
        return storageValue;
    }
    return cacheValue;
}

布隆过滤器

更具体的布隆过滤器原理以及实现可以查看Redis—布隆过滤器-CSDN博客

布隆过滤器是一个非常神奇的数据结构，通过它我们可以非常方便地判断一个给定数据是否存在于海量数据中。我们需要的就是判断 key 是否合法，有没有感觉布隆过滤器就是我们想要找的那个“人”。

具体是这样做的：把所有可能存在的请求的值都存放在布隆过滤器中，当用户请求过来，先判断用户发来的请求的值是否存在于布隆过滤器中。不存在的话，直接返回请求参数错误信息给客户端，存在的话才会走下面的流程。

加入布隆过滤器之后的缓存处理流程图如下。

但是，需要注意的是布隆过滤器可能会存在误判的情况。总结来说就是： 布隆过滤器说某个元素存在，小概率会误判。布隆过滤器说某个元素不在，那么这个元素一定不在。

为什么会出现误判的情况呢? 我们还要从布隆过滤器的原理来说！

我们先来看一下，当一个元素加入布隆过滤器中的时候，会进行哪些操作：

1. 使用布隆过滤器中的哈希函数对元素值进行计算，得到哈希值（有几个哈希函数得到几个哈希值）。
2. 根据得到的哈希值，在位数组中把对应下标的值置为 1。

我们再来看一下，当我们需要判断一个元素是否存在于布隆过滤器的时候，会进行哪些操作：

1. 对给定元素再次进行相同的哈希计算；
2. 得到值之后判断位数组中的每个元素是否都为 1，如果值都为 1，那么说明这个值在布隆过滤器中，如果存在一个值不为 1，说明该元素不在布隆过滤器中。

然后，一定会出现这样一种情况：不同的字符串可能哈希出来的位置相同。 （可以适当增加位数组大小或者调整我们的哈希函数来降低概率）

缓存雪崩

什么是缓存雪崩？

缓存雪崩描述的就是这样一个简单的场景：缓存在同一时间大面积的失效，后面的请求都直接落到了数据库上，造成数据库短时间内承受大量请求。 这就好比雪崩一样，摧枯拉朽之势，数据库的压力可想而知，可能直接就被这么多请求弄宕机了。

举个例子：系统的缓存模块出了问题比如宕机导致不可用。造成系统的所有访问，都要走数据库。

还有一种缓存雪崩的场景是：有一些被大量访问数据（热点缓存）在某一时刻大面积失效，导致对应的请求直接落到了数据库上。 这样的情况，有下面几种解决办法：

举个例子 ：秒杀开始 12 个小时之前，我们统一存放了一批商品到 Redis 中，设置的缓存过期时间也是 12 个小时，那么秒杀开始的时候，这些秒杀的商品的访问直接就失效了。导致的情况就是，相应的请求直接就落到了数据库上，就像雪崩一样可怕。

缓存雪崩的解决办法

针对 Redis 服务不可用的情况：

1. 采用 Redis 集群，避免单机出现问题整个缓存服务都没办法使用。
2. 限流，避免同时处理大量的请求。

针对热点缓存失效的情况：

1. 设置不同的失效时间比如随机设置缓存的失效时间。
2. 缓存永不失效。

缓存击穿

什么是缓存击穿？

缓存击穿是指 ‌某个热点数据在缓存过期（失效）的瞬间‌，大量并发请求直接穿透缓存，全部打到数据库上，导致数据库负载骤增甚至崩溃的现象。

缓存击穿的解决办法

1. 互斥锁：

原理‌：当缓存失效时，只允许一个线程去查询数据库并重建缓存，其他线程等待锁释放后直接读取新缓存。
‌实现方式‌：

• ‌分布式锁‌（如 Redis 的 SETNX 或 Redisson 的 RLock）。
• ‌本地锁‌（单机环境下可用 synchronized 或 ReentrantLock）。

2. 永不过期：

原理‌：缓存不设置过期时间，通过 ‌异步线程定期更新缓存‌（如定时任务或消息队列触发）。
‌实现方式‌：

• 缓存设置为永久有效。
• 通过后台任务或事件驱动更新数据。

3. 缓存预热

‌原理‌：在系统启动或低峰期，提前加载热点数据到缓存，避免首次请求穿透。
‌实现方式‌：

• 统计历史热点数据（如 Top-N 访问 Key）。
• 通过脚本或定时任务预加载缓存。

‌适用场景‌：

• 电商大促前预加载秒杀商品数据。
• 新闻类应用预加载头条内容。

区别对比

维度	缓存穿透	缓存雪崩	缓存击穿
‌触发条件‌	请求的数据==‌既不在缓存，也不在数据库‌==（如无效ID、恶意攻击）	‌大量缓存同时失效‌（如集体过期或缓存服务宕机）	‌单个热点数据过期失效‌（如秒杀商品缓存到期）
‌影响范围‌	单个或多个无效数据请求	‌全局性‌（大量缓存失效，导致数据库压力骤增）	‌局部性‌（仅某个热点数据失效，但并发极高）
‌请求特征‌	大量==‌无效请求‌==（恶意或业务缺陷）	大量==‌有效请求‌==因缓存失效直接访问数据库	大量==‌有效请求‌==集中访问同一失效热点数据
‌解决方案‌	1. 布隆过滤器 2. 缓存空值 3. 接口鉴权	1. 随机过期时间 2. 多级缓存 3. 熔断降级	1. 互斥锁 2. 逻辑过期 3. 永不过期策略
‌典型场景‌	爬虫恶意扫描不存在的ID	缓存服务宕机或批量设置相同TTL	微博热搜、秒杀活动等高并发场景