2. 缓存穿透原理与危害：穿透的定义、发生场景与雪崩风险
2.1 缓存穿透的定义
缓存穿透是指查询一个根本不存在的数据，由于缓存层不命中，每次请求都直接穿透到后端数据库，导致数据库承受大量本应由缓存拦截的无效查询。穿透的本质是缓存层对不存在数据的保护缺失。
核心公式：穿透率 = 穿透到数据库的请求数 / 总请求数。当穿透率持续 > 30% 时，数据库负载将出现非线性增长。
2.2 发生场景分析
缓存穿透主要发生在以下两类典型场景中：
| 场景类型 | 触发原因 | 典型特征 | 危害等级 |
|---|---|---|---|
| 恶意攻击 | 攻击者构造大量不存在的 Key（如随机 ID、负数 ID、超长字符串） | 请求 Key 分布离散、无规律；QPS 突增 | ★★★★★ |
| 空数据查询 | 业务查询不存在的数据（如已删除的商品、未注册的用户） | Key 有业务含义但数据已过期或被清理 | ★★★☆☆ |
| 缓存预热缺失 | 系统刚上线或缓存清空后，大量冷数据请求涌入 | 短时间内缓存命中率从 0% 开始爬升 | ★★★☆☆ |
| 参数校验缺陷 | 前端未对输入参数做合法性校验，非法参数直接进入后端 | 请求参数包含特殊字符、超范围数值 | ★★☆☆☆ |
工程警示：恶意攻击场景下的穿透流量往往在 1-2 秒内达到数据库连接池上限，导致正常业务请求也被阻塞。2021 年某电商平台因未做穿透防护，被攻击者用 10 万个不存在的商品 ID 打垮了 MySQL 集群。
2.3 穿透对后端数据库的冲击
数据库承受穿透请求时，会发生以下连锁反应：
- 连接池耗尽：每个穿透请求占用一个数据库连接，连接池满后新请求排队等待，响应时间从毫秒级飙升到秒级。
- 磁盘 IO 暴增：数据库需要执行全表扫描或索引查找不存在的数据，大量无效 IO 挤占正常查询的磁盘带宽。
- CPU 飙升：数据库解析 SQL、执行查询计划、返回空结果集的过程消耗 CPU，导致正常查询的响应时间增加 3-5 倍。
- 主从延迟：大量只读穿透请求压到从库，导致从库无法及时同步主库的 binlog，主从延迟从毫秒级扩大到秒级甚至分钟级。
性能数据参考：在 4 核 8G 的 MySQL 实例上，1000 QPS 的正常查询 CPU 使用率约 20%；同样 QPS 的穿透查询（空结果）CPU 使用率可达 70% 以上，因为每次查询都要走完整的索引扫描流程。
2.4 雪崩风险传导路径
缓存穿透引发的雪崩效应遵循以下传导路径：
2.5 穿透与击穿、雪崩的对比
缓存穿透常与缓存击穿、缓存雪崩混淆，三者的核心差异如下：
| 概念 | 触发条件 | 影响范围 | 典型 QPS 阈值 | 恢复难度 |
|---|---|---|---|---|
| 缓存穿透 | 查询不存在的数据 | 单个 Key 或多个不存在的 Key | 1000+ QPS 即可压垮单库 | 中等（需加空值缓存或布隆过滤器） |
| 缓存击穿 | 热点 Key 过期瞬间大量并发 | 单个热点 Key | 10000+ QPS 集中到单 Key | 较低（加互斥锁或永不过期） |
| 缓存雪崩 | 大量 Key 同时过期或缓存节点宕机 | 整个缓存层 | 全量请求穿透 | 高（需提前做缓存高可用和过期时间打散） |
工程经验：穿透防护是缓存治理的第一道防线。在笔者的项目中，仅通过空值缓存 + 布隆过滤器两层防护，就将数据库的无效查询从日均 200 万次降低到 200 次以下，穿透率从 35% 降至 0.03%。
2.6 穿透危害的量化评估模型
在实际工程中，建议使用以下公式评估穿透危害的严重程度：
# 穿透危害指数（PHI）计算公式
PHI = (穿透 QPS × 单次查询耗时 × 数据库连接池大小) / (缓存命中率 × 数据库最大并发)
# 示例：穿透 QPS=500，单次查询耗时=50ms，连接池=100，命中率=0.2，最大并发=200
PHI = (500 × 0.05 × 100) / (0.2 × 200) = 2500 / 40 = 62.5
# 危害等级判定
PHI < 10: 低风险，可监控观察
10 ≤ PHI < 50: 中风险，建议加空值缓存
PHI ≥ 50: 高风险，必须立即接入布隆过滤器或限流
关键提醒：PHI 指数超过 50 时，数据库的 CPU 使用率通常在 5 秒内从 20% 飙升到 90% 以上，触发告警后留给运维的响应窗口只有 10-15 秒。建议在 PHI 达到 30 时提前介入治理。