缓存穿透、缓存击穿、缓存雪崩的定义与区别
在分布式缓存系统中，缓存穿透、缓存击穿和缓存雪崩是三种最常见的高频故障模式。三者虽然都表现为缓存失效后请求直接打到后端存储（数据库、磁盘或下游服务），但触发场景、影响范围和治理手段截然不同。理解三者的本质区别，是设计缓存一致性治理方案的前提。
2.1 三种故障模式的定义
| 故障模式 | 核心定义 | 触发条件 | 影响范围 |
|---|---|---|---|
| 缓存穿透 | 请求查询一个根本不存在的数据（key 不存在于缓存和数据库中） | 恶意攻击、非法 key、数据未初始化 | 单次请求穿透，但大量并发时压垮数据库 |
| 缓存击穿 | 一个热点 key 在缓存过期瞬间，大量并发请求同时穿透到数据库 | 热点 key 过期 + 高并发 | 单个热点 key 失效，导致数据库瞬时高负载 |
| 缓存雪崩 | 大量缓存 key 在同一时间或短时间内集中过期，导致请求全部穿透到数据库 | 批量 key 同时过期、缓存节点宕机 | 全局性故障，可能导致数据库崩溃 |
关键区分点：穿透针对不存在的数据；击穿针对单个热点 key 过期；雪崩针对大量 key 同时过期或缓存节点整体不可用。
2.2 三种故障模式的流程对比
下图展示了三种故障模式下请求从客户端到数据库的完整路径。注意观察缓存层与数据库层之间的流量变化。
2.3 三种故障模式的详细对比
| 对比维度 | 缓存穿透 | 缓存击穿 | 缓存雪崩 |
|---|---|---|---|
| 数据是否存在 | 不存在（非法 key） | 存在（热点 key） | 存在（大量 key） |
| 并发特征 | 单次穿透，但可被攻击放大 | 高并发集中在单个 key | 高并发分散在多个 key |
| 缓存状态 | 始终无缓存 | 缓存刚过期 | 缓存批量过期或节点不可用 |
| 数据库压力 | 持续低负载或突发高负载 | 瞬时高负载 | 持续高负载直至崩溃 |
| 典型场景 | 恶意扫描不存在的 ID | 秒杀商品详情页 key 过期 | 缓存服务重启、批量 key 同时过期 |
| 治理难度 | 低（布隆过滤器 + 空值缓存） | 中（互斥锁 + 逻辑过期） | 高（过期时间打散 + 缓存高可用） |
2.4 三种故障模式的治理策略概览
在 Kubernetes 环境下，治理策略需要结合容器化部署的特点进行适配。下表列出每种故障模式的核心治理手段及其在 K8s 中的落地方式。
| 故障模式 | 核心治理手段 | K8s 环境落地方式 |
|---|---|---|
| 缓存穿透 |
|
|
| 缓存击穿 |
|
|
| 缓存雪崩 |
|
|
实践建议：在 Kubernetes 环境下，建议将缓存治理策略封装为 Operator 或 Sidecar，实现治理逻辑与业务代码的解耦。例如，布隆过滤器可以以 Sidecar 形式注入每个 Pod，热点 key 检测由 Operator 统一管理。
2.5 三种故障模式的识别与诊断
在实际生产环境中，快速识别故障类型是应急响应的第一步。以下诊断方法可以帮助运维人员快速定位问题。
- 缓存穿透诊断：监控数据库查询中 key 不存在的比例（空查询率）。如果空查询率突然升高且缓存命中率下降，大概率是穿透攻击。配合日志分析非法 key 的请求模式。
- 缓存击穿诊断：观察单个热点 key 的访问曲线。如果该 key 过期瞬间数据库 QPS 出现尖峰，且尖峰过后恢复正常，则为击穿。使用 Redis 的
MONITOR命令或慢查询日志辅助定位。 - 缓存雪崩诊断：检查缓存 key 的过期时间分布。如果大量 key 的 TTL 集中在同一时间窗口（如整点过期），且数据库负载呈阶梯式上升，则为雪崩。同时检查缓存节点是否发生批量重启或网络分区。
注意：三种故障可能同时发生。例如，缓存雪崩导致大量 key 失效，其中包含热点 key 引发击穿，同时攻击者利用空 key 进行穿透。治理时需要分层防御，不能只针对单一场景。
2.6 三种故障模式的治理优先级
在资源有限的情况下，建议按照以下优先级进行治理：
- 第一优先级：缓存雪崩——影响范围最大，可能导致整个系统不可用。优先通过过期时间打散、缓存高可用、多级缓存等手段降低风险。
- 第二优先级：缓存穿透——容易被恶意利用，且治理成本低（布隆过滤器 + 空值缓存）。建议作为基础防御手段默认开启。
- 第三优先级：缓存击穿——影响范围相对较小，但治理复杂度较高。建议结合业务热点识别，对核心热点 key 单独配置保护策略。