缓存穿透恶意攻击的故障隔离核心是前置布隆过滤器拦截，请求一进来即执行bf.exists判断，仅“可能存在”才进入后续流程；误判率宜设0.1%，需预估总量并用bf.reserve初始化，严禁将其置于缓存查询之后。

缓存穿透恶意攻击的故障隔离，核心是把无效请求在抵达缓存和数据库之前就“卡住”，不让它继续往下走。不是等它打到 Redis 再判断，更不能放行到数据库才返回空——那样已经晚了。

布隆过滤器必须前置部署

这是最硬的一道隔离墙。它要放在网关或接入层，请求一进来就执行 BF.EXISTS 判断。只有布隆过滤器认为“可能存在”，才允许进入后续流程（查 Redis → 查 DB）。

• 误判率控制在 0.1% 是较优平衡点，兼顾内存占用与拦截效果
• 初始化时预估总量（比如 1000 万有效 ID），用 BF.RESERVE 避免运行中扩容失败
• 切忌把布隆过滤器放在缓存查询之后——那等于先让请求穿过网络、消耗 Redis 连接、占位内存，完全失去隔离意义

空值缓存要带条件和扰动

布隆过滤器拦不住“新出现的非法 key”（比如攻击者持续生成 UUID），所以需要第二层兜底：对确认为空的结果做有节制的缓存。

• 只对高频重复出现的无效 key 缓存空值，例如同一参数在 1 分钟内被请求 ≥3 次才触发
• TTL 必须加随机扰动，比如 300 + random(0, 60) 秒，避免大量空值在同一秒过期引发二次穿透
• 统一用标记字符串（如 "__EMPTY__"）代替 null 或空字符串，防止业务逻辑混淆

运行时黑名单分层管理

针对绕过布隆过滤器的新攻击模式（如短时间突增的非法 pattern），需动态维护黑名单，但不能一刀切：

• 热黑名单：基于实时流量识别（如 1 秒内某前缀请求超 50 次），存于 Redis 的 Set 或 Sorted Set，TTL 设为 5–10 分钟
• 冷黑名单：由离线任务或人工审核确认的长期恶意 pattern，写入本地配置或持久化存储，重启不丢失
• 网关层做匹配拦截，命中即 400 返回，不进业务链路

参数校验与限流熔断协同

隔离不是单点动作，得和已有防御机制联动：

• 接口层强校验 ID 格式（如商品 ID 必须为正整数且 ≥100000）、范围（如用户 ID 不超过系统最大值）
• 对高风险接口（如 /item/detail）配置 QPS 限流，单 IP 或用户维度做速率限制
• 当数据库慢查询率或空响应率突增时，自动触发熔断，临时降级为固定响应或返回缓存兜底页