缓存失效引发击穿/穿透/雪崩的核心是批量无效请求直冲数据库，需紧盯缓存命中率断崖、空查询暴涨、参数异常集中三指标。
排查缓存失效处理不当引发的类似 DDoS 效果的击穿（实际多为穿透或雪崩叠加击穿），关键不是盯着“是不是被攻击”，而是快速定位请求是否在不该打数据库的时候，批量、高频、无意义地落到了数据库上。重点看三点：缓存命中率断崖、数据库空查询暴涨、请求参数异常集中。
看缓存命中率是否出现非预期下跌
命中率从 95%+ 突然掉到 60% 以下，尤其伴随时间点规律（比如整点、每 5 分钟一次），大概率不是流量自然增长，而是缓存集体失效或大量无效请求涌入。注意区分：
- 缓慢下降 → 可能是热点 key 逐个过期（击穿前兆）
- 阶梯式下跌（如 95% → 70% → 30%）→ 很可能是穿透 + 雪崩叠加，比如恶意遍历 ID 同时遇上一批商品缓存集中过期
- 命中率归零或接近零 → 要立刻查 Redis 是否宕机、客户端连接是否全断、序列化是否异常导致写入失败
查数据库慢查询日志里的“空结果”SQL
真正造成 DDoS 式压力的，往往不是正常业务查询，而是大量返回空结果的语句。打开 MySQL 的 slow log 或通用日志，过滤执行时间短（
- WHERE 条件中使用了明显非法值，如 id = -1、sku_code = ''、user_id = 0
- IN 查询包含数百个随机 ID，且绝大多数不在数据库中
- 带模糊匹配（LIKE '%xxx%'）或未走索引的空条件查询
这类请求单次代价低，但并发一高，连接池、CPU、IO 全线告急——比真实业务查询更伤数据库。
抓应用层请求参数分布
在网关或业务入口加一层轻量采样（如每千次取 1 次），统计请求路径和关键参数的分布情况。重点观察：
- 同一接口下，某个参数（如 product_id）是否出现大量重复无效值，或呈现明显递增/递减扫描特征（如 1000001, 1000002, 1000003…）
- 请求 User-Agent 是否高度集中于某几个爬虫标识，或为空 / 极简字符串
- 来源 IP 是否集中在少数出口（如某 IDC 段、某代理池），且 QPS 突增无业务上下文
发现上述模式，基本可判定是穿透型流量，而非正常用户行为。
验证空值是否被缓存或过滤
这是最常被忽略的一环。用一个确认不存在的 ID（如数据库里绝对没有的 999999999）手动调用接口，观察：
- 第一次请求是否触发了 DB 查询？
- 第二次相同 ID 请求，是否仍查 DB？还是直接返回？
- Redis 中是否存在该 key（哪怕值是空或特殊标记）？过期时间设的是多少？
如果两次都查 DB，说明空值没缓存；如果 Redis 里有但过期太长（如 24 小时），又可能被恶意利用占满内存；如果压根没进 Redis（比如布隆过滤器误判后直接拦截），那要检查过滤器加载逻辑是否完整、是否支持热更新。
