大家好，我是数据库小学妹👋我踩过的坑，你别再踩。

618凌晨我值班，凌晨一点二十分，监控群同时弹出17条告警。Redis命中率从98%断崖式跌到23%。MySQL连接池直接打满。网关返回502的时间，每单支付平均慢了四秒。事后查了三个小时，根因是一批过期key的TTL设成了同一秒。同一时间全部过期，几千个请求同时打到数据库。这就是典型的缓存雪崩。

这次事故让我意识到，缓存穿透、击穿、雪崩这三个词很多教程混着讲，但底层机制完全不同，防御策略也完全不同。今天我把生产环境验证过的方案完整拆开讲，希望能帮你少走弯路少踩坑。

## 先说结论：三者不是一个东西

先看一张对比表，一眼分清。

| 维度 | 缓存穿透 | 缓存击穿 | 缓存雪崩 |
|---|---|---|---|
| 触发条件 | 查询不存在的key | 单个热点key过期瞬间 | 大量key同时过期 |
| 命中情况 | 永远不会命中 | 命中瞬间归零后恢复 | 命中率断崖式下降 |
| 攻击面 | 恶意请求或脏数据 | 正常业务热点数据 | TTL集中到期 |
| DB压力 | 持续高，无效查询 | 瞬时打满 | 瞬间洪峰 |
| 核心防御 | 布隆过滤器+空值缓存 | 分布式锁+逻辑过期 | TTL随机化+多级缓存 |
| 排查特征 | 请求分散无热点key | 某个key请求量异常集中 | 大量key同时miss |

搞混了防御手段，等于用创可贴止大动脉出血。

## 第一案：缓存穿透，查一个永远不存在的数据

商品表有100万条数据，有人恶意请求ID为999999999的商品。这个ID不存在，缓存里自然没有。每次请求都穿透到数据库，一万次就是万次无效查询，数据库CPU直接飙到90%。

穿透的本质是**缓存层没有拦截无效请求的能力**。每一次miss都变成一次数据库查询。请求量大的话数据库连接池很快被打满，正常的业务请求也被阻塞。

生产方案用**布隆过滤器加空值缓存**。布隆过滤器解决的是快速判断key是否存在。底层是一个二进制位数组加上多个哈希函数。元素经过多个哈希映射到位数组的多个位置。查询时只要有一个位置是0就说明不存在。误判率可调，但不会漏判。它说不存在的一定不存在。它说存在的小概率不存在。

```java
// Guava BloomFilter 初始化
BloomFilter<String> bf = BloomFilter.create(
    Funnels.stringFunnel(Charset.forName("UTF-8")),
    1000000,  // 预期元素量
    0.01      // 误判率1%
);

// 预加载所有存在的商品ID
for (Long id : allProductIds) {
    bf.put(String.valueOf(id));
}

// 查询时先过布隆过滤器
public Product getProduct(Long id) {
    String key = "product:" + id;
    if (!bf.mightContain(String.valueOf(id))) {
        return null;  // 布隆说没有，直接返回
    }
    Product p = redis.get(key);
    if (p != null) return p;  // 缓存有直接返回
    p = db.getById(id);
    if (p != null) {
        redis.setex(key, 3600, p);
    } else {
        redis.setex(key, 60, "NULL");  // 数据库也没有，缓存空值
    }
    return p;
}
```

空值缓存的TTL设60秒到120秒。设太长的话万一新数据写入缓存还是旧的null。设太短防不住高频攻击。

我踩过的坑是布隆过滤器误判率一开始设了0.001。当时以为精度越高越好，结果内存占了好几百兆。后来改成0.01，误判率1%对缓存场景完全可接受，内存降了一个数量级。不过如果是安全敏感场景，0.001仍有必要，不能一概而论。业内推荐误判率在0.1%到5%之间就够。

还有个坑是布隆过滤器不支持删除。商品下架后位数组无法回退。我的做法是定期重建过滤器，凌晨两点全量刷一次。如果业务删除频繁，可以考虑布谷鸟过滤器，它支持删除操作，RedisBloom也原生支持。

对了，上面代码用的是Guava本地布隆过滤器。如果数据量大或者需要多实例共享，可以用RedisBloom模块。Redis 4.0之后就有这个模块，直接用BF.RESERVE、BF.ADD、BF.EXISTS命令操作。100万个ID大约只需1.2MB内存，过滤器和Redis同进程，没有额外网络开销。

## 第二案：缓存击穿，热点key过期的那一秒

首页推荐位有一个热点key，QPS三万，TTL设了300秒。第五分钟整key过期，同一瞬间200个线程同时发现key不在缓存。200个线程同时查数据库，连接数瞬间打满。

击穿和穿透的区别在于**数据本身存在**，只是缓存恰好在这个时间点过期。大量并发请求同时miss，瞬时压力比穿透更集中。

分布式锁的核心思路是key过期时只让一个线程去查数据库重建缓存，其他线程等待或返回旧值。

```java
public Product getHotProduct(Long id) {
    String key = "product:" + id;
    String lockKey = "lock:product:" + id;
    Product p = redis.get(key);
    if (p != null) return p;

    boolean locked = redis.setIfAbsent(lockKey, "1", 10, TimeUnit.SECONDS);
    if (!locked) {
        Thread.sleep(100);  // 等100ms再查一次
        return redis.get(key);  // 大概率另一个线程已重建
    }
    try {
        p = db.getById(id);  // 拿到锁的线程查DB重建
        if (p != null) redis.setex(key, 300, p);
    } finally {
        redis.delete(lockKey);
    }
    return p;
}
```

但SETNX实现的分布式锁有个隐患。线程拿到锁后如果异常退出，锁可能不会释放。其他线程永远等不到。生产环境用Redisson。它有看门狗机制，默认30秒自动续期。线程异常退出后锁自动释放。

```java
RLock lock = redisson.getLock(lockKey);
try {
    if (lock.tryLock(3, 10, TimeUnit.SECONDS)) {
        p = db.getById(id);
        redis.setex(key, 300, p);
    }
} finally {
    if (lock.isHeldByCurrentThread()) {
        lock.unlock();
    }
}
```

有些场景不允许线程等待，比如响应时间要求200ms以内。这时候用逻辑过期。缓存value里自带过期时间字段，实际Redis的TTL设成很长。查询时判断逻辑过期时间是否到了，到了就让后台线程异步重建，其他线程返回旧值。

```java
@Data
class CacheWrapper<T> {
    private T data;
    private long expireTime; // 逻辑过期时间戳
}

public Product getProductWithLogicalExpire(Long id) {
    String key = "product:" + id;
    CacheWrapper<Product> wrapper = redis.get(key);
    if (wrapper == null) return loadAndCache(id);
    if (System.currentTimeMillis() > wrapper.getExpireTime()) {
        executor.submit(() -> loadAndCache(id));  // 逻辑过期，异步重建
    }
    return wrapper.getData();  // 当前返回旧值
}
```

这个方案零等待，缺点是可能返回过期数据，对一致性要求高的场景不适用。我当时的选择标准是用户中心用分布式锁方案要求强一致，商品详情页用逻辑过期允许秒级延迟，首页推荐用逻辑旧数据不影响体验。

## 第三案：缓存雪崩，TTL集中到期的连锁反应

这就是开头618事故的那一幕。促销活动期间上了5000个新商品，运营批量导入时缓存TTL统一设了3600秒。一小时整5000个key同时过期，每秒几千个miss涌向数据库。MySQL CPU从15%飙到98%，主从延迟超过30秒。

雪崩和击穿的区别在于**规模**。击穿是单个key，雪崩是大批key集中在同一时间点过期，压力不是一个量级。雪崩的另一个诱因是**Redis节点宕机**，整个缓存层不可用，所有请求直接打到数据库，这比TTL过期更致命。

TTL随机化是最基础的防御。给每个key的过期时间加上随机偏移量。

```java
int baseTtl = 3600;
int randomTtl = baseTtl + ThreadLocalRandom.current().nextInt(300);
redis.setex(key, randomTtl, value);
```

偏移量设基础TTL的5%到10%。三千六百秒加三百秒随机，key的过期时间就均匀分布在六十一分钟内，不会同时到期。

多级缓存是更稳的方案。本地缓存Caffeine做第一层，Redis做第二层，数据库是最后兜底。Redis挂的时候本地缓存还能扛一阵。

```java
public Product getMultiLevel(Long id) {
    String key = "product:" + id;
    Product p = localCache.getIfPresent(key);
    if (p != null) return p;  // 第一层本地缓存
    p = redis.get(key);
    if (p != null) {
        localCache.put(key, p);
        return p;  // 第二层Redis
    }
    p = db.getById(id);
    if (p != null) {
        redis.setex(key, 3600, p);
        localCache.put(key, p);  // 第三层数据库
    }
    return p;
}
```

降级熔断是最后的防线。用Sentinel或Resilience4j，数据库响应时间超过阈值就触发降级，直接返回兜底数据。

```java
SentinelConfig.loadRules(List.of(
    new DegradeRule("dbQuery")
        .setGrade(CircuitBreakingStrategy.SLOW_REQUEST_RATIO)
        .setSlowRatioThreshold(0.5)
        .setTimeWindow(30)
        .setMinRequestAmount(20)
));
```

## 监控和告警：别等炸了才知道

这三个问题的共同点是发现的时候已经炸了。事后我补了这套监控。关键指标有四个。
* 缓存命中率按小时统计，miss率突增超过10%就要告警。
* Redis慢查询日志设10毫秒阈值。
* 每秒miss数的QPS曲线，陡增必有异常。
* 数据库连接池使用率超过80%就预警。
Grafana大盘上我把这四个指标放在一起，配合Redis自带的INFO命令。instantaneous_ops_per_sec看吞吐，keyspace_hits和keyspace_misses算命中率，connected_clients看连接数。

除了监控，还有两件事要提前做。一是Redis集群高可用，生产环境建议主从加哨兵或Redis Cluster，避免单点故障直接引发雪崩。二是新业务上线前做好缓存预热，别让第一批请求直接打到数据库。

## 避坑清单

布隆过滤器误判率在0.1%到5%之间就够，缓存场景1%完全可接受，不是越低越好。安全敏感场景可以设更低，但普通业务没必要追求千分之一。

缓存空值的TTL要单独管理，别和业务数据用同一套策略，太长会导致新数据写入后仍然返回null，太短起不到防护作用。

Redisson看门狗默认30秒续期，业务查询耗时超过30秒锁会被其他线程抢走，慢查询场景要把watchdogTimeout调大或改用tryLock带超时参数。

TTL随机化的偏移量别超基础值的百分之十，偏移量太大会拉长数据一致性窗口。雪崩场景下别用KEYS命令排查，生产环境执行KEYS会让Redis阻塞十几秒，用SCAN代替。商品删除频繁的场景可以考虑布谷鸟过滤器替代布隆过滤器，它支持删除操作。

你们生产环境遇到过哪种缓存事故？布隆过滤器和逻辑过期你们选哪种？评论区聊聊你的方案。

我是数据库小学妹，帮你少走弯路少踩坑，咱们下篇见👋


618凌晨我值班，凌晨一点二十分，监控群同时弹出17条告警。Redis命中率从98%断崖式跌到23%。MySQL连接池直接打满。网关返回502的时间，每单支付平均慢了四秒。事后查了三个小时，根因是一批过期key的TTL设成了同一秒。同一时间全部过期，几千个请求同时打到数据库。这就是典型的缓存雪崩。

Redis缓存穿透、击穿、雪崩的底层机制与防御方案，附完整代码

从618促销缓存雪崩事故切入，深度解析缓存穿透、击穿、雪崩的底层机制、生产级防御方案与监控告警策略，附布隆过滤器实现和分布式锁代码

架构设计

缓存穿透、击穿、雪崩三者机制不同，防御策略各异。穿透用布隆过滤器+空值缓存，击穿用分布式锁+逻辑过期，雪崩用TTL随机化+多级缓存。生产环境需监控命中率、慢查询、连接池，配合Redis高可用与缓存预热，避免618式事故。

数据库连接池

数据一致性

哈希函数

代码解释

数据库

MySQL

Redis

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

Redis缓存穿透、击穿、雪崩的底层机制与防御方案，附完整代码-腾讯云开发者社区-腾讯云

Redis缓存穿透、击穿、雪崩的底层机制与防御方案，附完整代码

Redis缓存穿透、击穿、雪崩的底层机制与防御方案，附完整代码

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐