缓存穿透、击穿、雪崩：三个总被混为一谈的故障

面试里被问「缓存击穿和雪崩有什么区别」，十个人里有六个答不上来——不是因为难，是因为**这两个词在国内的流传过程中被混用了**。

这篇先把定义钉死，再给解法。

先分清：查询的三种「没拿到」

所有缓存故障，都可以还原成一个问题：**一次读请求没拿到想要的数据，它去哪了？**

- **穿透** = 查的东西压根没有，缓存**挡不住**，因为它不知道你要什么

- **击穿** = 查的东西一直有，缓存**刚好失效**，那一个瞬间挡不住

- **雪崩** = 查的东西一直有，缓存**整体垮了**，谁都挡不住

⚠ **命名警告**：击穿在英文里是 Cache Breakdown，也常被叫 Hotspot Invalidation；雪崩是 Cache Avalanche。但很多团队的文档里这两个是互换的。**面试时先问对方「你们怎么定义」，比背定义有用。**

一、缓存穿透：查不存在的数据

攻击者用一个不存在的 ID 列表刷你的接口：`/user?id=1`、`/user?id=2`……

每个请求都是：查缓存 → 未命中 → 查 DB → 未找到 → 不写缓存。DB 被打满，而缓存里**一个字节都没多**。

更隐蔽的版本：某个字段线上是 null，比如 `user.phone`，大量用户没填。你查了 100 万次 null，缓存永远是空的。

查不到也写进去，TTL 设短（30 秒到 5 分钟）：

cache.set(key, NULL_PLACEHOLDER, 60); // ← 关键

简单有效，但拦不住「攻击者每次换一个不存在的 ID」——空值缓存只对**重复查询同一个 key** 有效。

启动时把所有合法 ID 灌进布隆位图。查询时先问它：

return NOT_FOUND; // 一定不存在，直接返回，不碰 DB

它有假阳性（说「可能在」但其实不存在），但**不会有假阴性**（说「不在」就是真不在）。所以它适合做**第一道拦截**，把绝大多数恶意请求挡在 DB 之外。

代价：位图有空间开销，且删除元素困难（需要 Counting Bloom 或定期重建）。

最朴素也最容易被忽略：`id` 是不是正数、是不是合法格式。不合法直接 400，别往下传。

二、缓存击穿：一个热点 key 失效的瞬间

有个爆款商品的 key，QPS 一万。平时缓存命中，风平浪静。

某天这个 key 到了 TTL，或者被人手动删了。**接下来 1 秒内**，一万个请求同时发现缓存没了，同时去查 DB，同时试图写回。

DB 被打出一个尖峰，然后可能就挂了。

只让第一个线程去查 DB，其他线程等它查完再读缓存：

Object lock = locks.computeIfAbsent(key, k -> new ReentrantLock());

if (lock.tryLock(0, TimeUnit.MILLISECONDS)) {

// 双重检查：等锁期间可能别人已经填好了

locks.remove(key); // ★ 必须移除，否则内存泄漏

// 没抢到锁 → 短暂自旋后重读缓存

⚠ 两个坑：**锁一定要在 finally 里 remove**，否则 key 多了锁表也跟着涨；另外要**双重检查**，因为你等锁的这段时间里，别人可能已经把值填进缓存了。

不给 key 真的设 TTL，而是在值里塞一个 `expireAt` 时间戳：

// 逻辑上过期了，但**物理上还在**，直接返回旧值

asyncRefresh(key); // 后台异步刷新，不阻塞

好处是**永远不会出现「全部同时失效」**——刷新是异步的，一个一个来。代价是牺牲了短暂的数据新鲜度，换可用性。在电商大促这种场景，这个取舍很划算。

- **大量 key 同一时刻过期**。比如批量预热时 TTL 都设成了 3600 秒，那这一批就在整点同时炸。

- **缓存服务本身挂了**。Redis 主节点故障、网络分区、连接池打满。

区别在于：击穿是**一个** key，雪崩是**一大片**。

不要所有 key 用同一个 TTL。加随机：

long ttl = baseTtl + ThreadLocalRandom.current().nextLong(0, 600); // 0~10min 抖动

一行代码，把「同时过期」变成「陆续过期」。

本地缓存 + Redis。本地缓存在 Redis 挂掉时还能扛一波：

if (v2 != null) { localCache.put(key, v2, 30, SECONDS); return v2; }

代价是**一致性问题被放大**：本地缓存里的数据在多台机器上不一致，容忍窗口最长 30 秒。业务上能不能接受这个窗口，是选型的前提。

Redis 挂了不要让请求全部堆到 DB 上。挂个熔断器，DB 的 QPS 超过阈值就**快速失败**：

return DEGRADED_RESPONSE; // 返回兜底数据，而不是拖死 DB

宁可返回「稍后重试」，也不要把 DB 一起拖下水。

**④ 服务雪崩的最后一层：随机过期 + 提前预热**

Redis 重启后是**空的**，那一刻所有流量都会打到 DB。所以：

- 给每个节点的缓存 TTL 加随机偏移，避免所有节点**同时**冷启动

这三个问题的**共同点**是：请求绕过缓存直接打到 DB，而 DB 是整条链路上最脆弱的一环。

所以设计缓存时不要只想着「命中率」，要想**「最坏情况下会发生什么」**。缓存系统的设计难度，从来不在正常路径上。

「缓存击穿和雪崩有什么区别」十个人六个答不上来，不是因为难，是这两个词在国内流传中被混用了。本文先把定义钉死，再给每种故障的首选解法与兜底手段。

架构设计

缓存故障三兄弟：穿透（查不存在数据）、击穿（单热点key失效瞬间）、雪崩（大面积失效/服务挂）。解法：穿透用布隆过滤器+空值缓存，击穿用互斥锁+逻辑过期，雪崩用TTL随机打散+多级缓存+熔断降级。核心在于保护DB，考虑最坏场景。

Redis

Java

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

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

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

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

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

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

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

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

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

缓存穿透、击穿、雪崩：三个总被混为一谈的故障

缓存穿透、击穿、雪崩：三个总被混为一谈的故障

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐