MySQL高并发下缓存穿透击穿雪崩解决方案及实际案例解析

想象一下，你正在运营一个拥有千万级用户的电商或社交平台。就在“双11”或者某个明星突然爆火的瞬间，流量像海啸一样涌来。你的数据库（MySQL）是最后一道防线，但如果这道防线直接承受所有请求，瞬间就会崩溃。这时候，Redis 这样的内存缓存就成了你的“缓冲垫”。

但是，这个缓冲垫如果设计不好，不仅救不了场，反而会成为压垮系统的最后一根稻草。这就是我们今天要深入探讨的三大“缓存杀手”：缓存穿透、缓存击穿、缓存雪崩。

别被这些术语吓到，我会用大白话和真实的代码案例，带你彻底搞懂它们，并给出最落地的解决方案。

一、缓存穿透：查无此物，直击心脏

1. 什么是缓存穿透？

简单来说，就是用户查询了一个根本不存在的数据。

正常流程：先查 Redis -> 没查到 -> 查 MySQL -> 写入 Redis -> 返回数据。
穿透场景：用户一直请求 ID 为 -1 或者一个随机生成的、数据库中绝对没有的数据。
后果：Redis 中没有该数据，每次请求都会打到 MySQL 上。如果黑客恶意攻击，每秒几万次这样的请求，MySQL 直接被打挂。

2. 形象比喻

这就好比你问图书馆管理员：“我要找《火星基地建造指南》这本书。” 管理员去书架找，找不到；再去数据库查，也没有。如果你每秒钟问一万次这个问题，管理员就得跑一万趟库房确认“真的没有”，最后累死在岗位上。

3. 解决方案与实战代码

方案 A：缓存空对象（简单粗暴）

当发现 MySQL 中也没有这条数据时，我们在 Redis 中也存一个值，比如 null，并设置一个较短的过期时间（如 5 分钟）。这样后续请求直接命中 Redis 的空值，不再查库。

public String getData(int id) {
    // 1. 从缓存获取
    String key = "data_" + id;
    String value = redisTemplate.opsForValue().get(key);
    
    if (value != null) {
        // 区分空对象标记，防止误判
        if ("NULL".equals(value)) {
            return null;
        }
        return value;
    }

    // 2. 缓存为空，查数据库
    String dbData = mysqlMapper.selectById(id);
    
    if (dbData == null) {
        // 3. 数据库也没数据，缓存一个空对象，设置短过期时间
        redisTemplate.opsForValue().set(key, "NULL", 5, TimeUnit.MINUTES);
        return null;
    } else {
        // 4. 正常数据，缓存较长时间
        redisTemplate.opsForValue().set(key, dbData, 30, TimeUnit.MINUTES);
        return dbData;
    }
}

注意：这种方法有个缺点，如果业务中存在大量无效数据请求，Redis 会被大量无用的空对象占满。

方案 B：布隆过滤器（Bloom Filter）—— 专家推荐

这是更高级、更专业的做法。布隆过滤器像一个“黑名单”或“白名单”检查器。它在内存中占用极小空间，能快速判断一个元素一定不存在或可能存在。

原理：

将所有合法的数据 ID 放入布隆过滤器。
请求到来时，先问布隆过滤器：“这个 ID 存在吗？”
如果回答“不存在”，直接拦截，绝不查 DB 和 Redis。
如果回答“可能存在”，再走正常的 Redis -> MySQL 流程。

Java 实现示例（使用 Google Guava BloomFilter）：

import com.google.common.hash.BloomFilter;
import com.google.common.hash.Funnels;

public class DataCacheService {
    private BloomFilter<Integer> bloomFilter;
    private RedisTemplate<String, String> redisTemplate;

    public void init() {
        // 预期数据量 1000万，误判率 0.01
        int expectedInsertions = 10_000_000;
        double fpp = 0.01; 
        this.bloomFilter = BloomFilter.create(Funnels.integerFunnel(), expectedInsertions, fpp);
        
        // 初始化时，将数据库中所有有效ID加载进布隆过滤器
        List<Integer> allIds = mysqlMapper.selectAllIds();
        for (Integer id : allIds) {
            bloomFilter.put(id);
        }
    }

    public String queryData(int id) {
        // 第一步：布隆过滤器拦截
        if (!bloomFilter.mightContain(id)) {
            // 肯定不存在，直接返回，保护数据库
            System.out.println("请求被布隆过滤器拦截: " + id);
            return null;
        }
        
        // 第二步：可能存在，查缓存
        String cacheKey = "data_" + id;
        String cachedValue = redisTemplate.opsForValue().get(cacheKey);
        if (cachedValue != null) {
            return cachedValue;
        }
        
        // 第三步：查数据库
        String dbValue = mysqlMapper.selectById(id);
        if (dbValue != null) {
            // 写入缓存
            redisTemplate.opsForValue().set(cacheKey, dbValue, 30, TimeUnit.MINUTES);
            return dbValue;
        }
        
        // 如果数据库查不到但布隆过滤器说存在（极少见的误判），也可选择缓存空值
        return null;
    }
}

优点：极大减少 Redis 和 DB 的压力，即使面对恶意扫描也毫发无损。

四、缓存击穿：热点过期，千军万马

1. 什么是缓存击穿？

某个 Key 非常热门（热点数据），在它过期的那一瞬间，成千上万的请求同时到达。

此时 Redis 中该 Key 已失效。
所有请求都发现缓存没数据，于是同时涌向 MySQL。
虽然数据只有一条，但瞬间的高并发查询足以让 MySQL 宕机。

2. 形象比喻

图书馆里有一本畅销书《如何快速赚钱》，规定借期 1 小时。当第 60 分钟结束时，所有想借这本书的人同时冲进阅览室。管理员不得不同时处理几百个借阅请求，系统瞬间瘫痪。

3. 解决方案与实战代码

方案 A：互斥锁（Mutex Lock）—— 最常用

只允许一个线程去查数据库并重建缓存，其他线程等待或重试。

使用 Redis SETNX 实现分布式锁：

public String getHotData(String key) {
    // 1. 查缓存
    String value = redisTemplate.opsForValue().get(key);
    if (value != null) {
        return value;
    }

    // 2. 缓存为空，尝试加锁
    // setIfAbsent 相当于 redis.setnx
    boolean isLock = redisTemplate.opsForValue().setIfAbsent("lock_" + key, "1", 10, TimeUnit.SECONDS);
    
    if (isLock) {
        try {
            // 双重检查：拿到锁后，再次查看缓存是否已被其他线程重建
            value = redisTemplate.opsForValue().get(key);
            if (value != null) {
                return value;
            }
            
            // 3. 查数据库
            value = mysqlMapper.selectById(key);
            
            // 4. 写入缓存（设置合理过期时间）
            if (value != null) {
                redisTemplate.opsForValue().set(key, value, 30, TimeUnit.MINUTES);
            }
        } finally {
            // 5. 释放锁
            redisTemplate.delete("lock_" + key);
        }
    } else {
        // 6. 没拿到锁，休眠一会儿重试，或者直接返回旧值（如果有）
        // 这里简单起见，休眠后递归调用或返回空
        try {
            Thread.sleep(50);
            return getHotData(key); // 递归重试
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        }
    }
    return value;
}

注意：生产环境建议使用 Redisson 等成熟框架处理锁，避免死锁和复杂逻辑。

方案 B：逻辑过期（Logical Expiration）—— 高性能方案

不在物理上删除 Key，而是给 Key 设置一个较长的物理过期时间（如 1 天），但在 Value 中存储一个“逻辑过期时间”字段。

读取数据时，判断逻辑时间是否过期。
如果未过期，直接返回。
如果已过期，不删除 Key，而是启动一个后台线程去更新缓存。
主线程直接返回旧的缓存数据（保证高可用）。
后台线程更新完新数据后，主线程下次请求就能读到新数据。

这种方式完全避免了锁的竞争，适合对一致性要求不高、但对可用性要求极高的场景。

五、缓存雪崩：大面积失效，集体崩溃

1. 什么是缓存雪崩？

大量的 Key 在同一时间过期，或者 Redis 服务整体宕机。

如果是过期导致：大量请求同时打到 MySQL，DB 压力激增。
如果是宕机导致：所有请求都查不到缓存，全部打入 DB。

2. 形象比喻

整个图书馆的所有书都在中午 12:00 到期归还。下午 12:01，所有人都来借书，管理员忙不过来，图书馆关门。或者更糟糕的是，图书馆大门坏了（宕机），没人能进去借书，所有读者都在门口挤爆了。

3. 解决方案与实战代码

方案 A：过期时间加随机值

不要给所有 Key 设置相同的过期时间（如都是 30 分钟）。做法：基础过期时间 + 随机波动范围。例如：30分钟 + random(0, 5分钟)。这样可以让过期时间分散开，避免集中失效。

// 伪代码示例
int baseExpire = 30 * 60;
int randomExpire = new Random().nextInt(5 * 60);
int totalExpire = baseExpire + randomExpire;
redisTemplate.opsForValue().set(key, value, totalExpire, TimeUnit.SECONDS);

方案 B：高可用架构（Redis Cluster/Sentinel）

单点 Redis 容易宕机。必须搭建 Redis 集群（Cluster）或哨兵模式（Sentinel）。

数据分片存储，一台机器挂了，其他机器还能提供服务。
配合持久化（RDB/AOF），重启后能快速恢复数据。

方案 C：限流降级

当检测到 Redis 响应缓慢或大量超时，或者 MySQL CPU 飙升时，触发熔断机制。

限流：直接拒绝部分请求，返回“系统繁忙”或默认数据。
降级：返回静态页面或兜底数据。

可以使用 Sentinel 或 Hystrix/Resilience4j 来实现：

@HystrixCommand(fallbackMethod = "getDataFallback")
public String getData(int id) {
    // 正常逻辑
    return redisTemplate.opsForValue().get("key_" + id);
}

// 降级方法
public String getDataFallback(int id) {
    // 返回默认值或空字符串，避免报错
    log.warn("Redis异常，降级处理，id: " + id);
    return ""; 
}

六、综合最佳实践：构建坚不可摧的缓存体系

在实际项目中，这三种情况往往交织在一起。作为一个专家，我建议你采用以下组合策略：

预防穿透：
- 接口层做参数校验（如 ID 必须 > 0）。
- 关键业务接入布隆过滤器。
防止击穿：
- 热点数据使用互斥锁或逻辑过期策略。
- 识别热点 Key：通过监控统计 QPS，对高频访问的 Key 单独处理（如永不过期，靠后台异步刷新）。
抵御雪崩：
- 随机过期时间：所有缓存 Key 的 TTL 加上随机偏移量。
- 高可用部署：Redis 集群 + 多副本。
- 多级缓存：本地缓存（Caffeine/Guava Cache）+ 分布式缓存（Redis）。本地缓存作为第一道屏障，即使 Redis 挂了，本地缓存还能撑一会儿。

本地缓存 + 分布式缓存示例（Caffeine + Redis）

public String getDataWithMultiLevelCache(int id) {
    String localCacheKey = "local_data_" + id;
    String remoteCacheKey = "remote_data_" + id;

    // 1. 查本地缓存 (Caffeine)
    String localValue = caffeineCache.getIfPresent(localCacheKey);
    if (localValue != null) {
        return localValue;
    }

    // 2. 查分布式缓存 (Redis)
    String remoteValue = redisTemplate.opsForValue().get(remoteCacheKey);
    if (remoteValue != null) {
        // 同步到本地缓存
        caffeineCache.put(localCacheKey, remoteValue);
        return remoteValue;
    }

    // 3. 查数据库
    String dbValue = mysqlMapper.selectById(id);
    if (dbValue != null) {
        // 写入两级缓存
        redisTemplate.opsForValue().set(remoteCacheKey, dbValue, 30, TimeUnit.MINUTES);
        caffeineCache.put(localCacheKey, dbValue);
        return dbValue;
    }

    return null;
}

结语

缓存不是银弹，它是双刃剑。用得好，它能扛住千万级并发；用得不好，它就是系统的定时炸弹。

穿透要防，用布隆过滤器是王道。
击穿要控，互斥锁和逻辑过期是利器。
雪崩要避，随机过期和高可用是基石。

希望这篇解析能帮你建立起完整的缓存防护思维。在实际开发中，记得结合监控（如 Prometheus + Grafana）实时观察缓存命中率、QPS 和 DB 负载，动态调整策略。毕竟，最好的架构，是那些能随着业务增长而平滑演进的架构。

MySQL高并发下缓存穿透击穿雪崩解决方案及实际案例解析

一、 缓存穿透：查无此物，直击心脏

1. 什么是缓存穿透？

2. 形象比喻

3. 解决方案与实战代码

方案 A：缓存空对象（简单粗暴）

方案 B：布隆过滤器（Bloom Filter）—— 专家推荐

四、 缓存击穿：热点过期，千军万马

1. 什么是缓存击穿？

2. 形象比喻

3. 解决方案与实战代码

方案 A：互斥锁（Mutex Lock）—— 最常用

方案 B：逻辑过期（Logical Expiration）—— 高性能方案

五、 缓存雪崩：大面积失效，集体崩溃

1. 什么是缓存雪崩？

2. 形象比喻

3. 解决方案与实战代码

方案 A：过期时间加随机值

方案 B：高可用架构（Redis Cluster/Sentinel）

方案 C：限流降级

六、 综合最佳实践：构建坚不可摧的缓存体系

本地缓存 + 分布式缓存 示例（Caffeine + Redis）

结语

一、缓存穿透：查无此物，直击心脏

四、缓存击穿：热点过期，千军万马

五、缓存雪崩：大面积失效，集体崩溃

六、综合最佳实践：构建坚不可摧的缓存体系

本地缓存 + 分布式缓存示例（Caffeine + Redis）