布隆过滤器是解决缓存穿透最可控的手段，需部署在Redis之前拦截非法key；它不支持删除、存在误判率，须按真实数据量预估容量，并配合参数校验与限流使用。
布隆过滤器不是“银弹”，但它确实是解决缓存穿透最可控的手段——前提是它被正确集成到请求入口，且不被绕过。
为什么空值缓存拦不住恶意穿透
空值缓存（setex key 120 "@@EMPTY@@"）对正常业务有效，但面对攻击者用随机 user_id 或 UUID 疯狂刷接口时，会迅速堆积海量无效 key，吃光 Redis 内存。更关键的是：它只对“已查过的空 key”起作用，对全新、未见过的非法 key 完全无感。
- 攻击者每秒发 1000 个不存在的
user:abc123、user:def456，每个都触发一次 DB 查询 -
EMPTY_CACHE_TTL设太长（比如 30 分钟），新注册用户可能因历史空缓存而查不到 - 空值缓存无法区分“真不存在”和“暂时没数据”，逻辑上存在语义污染
布隆过滤器必须放在 Redis 之前
布隆过滤器（Bloom Filter）本质是内存中的概率型集合，只能回答“这个 key 可能存在”或“一定不存在”。它必须部署在缓存查询之前，否则就失去拦截意义。
- 正确链路：
请求 → 布隆过滤器 → （若“一定不存在”则直接返回）→ Redis → DB - 错误链路：
请求 → Redis → （未命中）→ 布隆过滤器 → DB—— 此时穿透已经发生 - 推荐用 Redis 自带的
bf.exists（RedisBloom 模块），或 Java 的guava BloomFilter+ 本地缓存兜底 - 初始化时要把所有合法
user_id、product_id全量哈希进去；增量数据需同步更新布隆结构
布隆过滤器的两个硬约束不能妥协
误判率（false positive rate）和容量（expected insertions）是布隆过滤器的一体两面，改一个必动另一个。生产环境必须按真实数据量预估，不能拍脑袋。
- 假设你有 1 亿个合法用户 ID，要求误判率 ≤ 0.1%，那布隆过滤器至少需要 ≈ 1.4 GB 内存（用标准公式计算）
- 如果用太小的 bitmap，误判率飙升，会导致大量合法请求被误杀，业务直接报错
- 布隆过滤器不支持删除，所以被软删除的 ID（如用户注销）仍会“存在”于过滤器中，需配合「逻辑删除 + TTL 缓存」兜底
- 别用
String拼接做简易布隆——它没有抗碰撞设计，攻击者可轻易构造哈希冲突绕过
必须搭配参数校验和限流才真正可靠
布隆过滤器防的是“不存在的 key”，但挡不住“存在却非法的请求”，比如 user_id = -1、user_id = "admin" 这类明显越权或格式错误的输入。
- 在布隆前加一层基础校验：
if (id - 对高频空响应路径（如
GET /user/{id}返回 404）做 QPS 限制，用 Redis 的INCR + EXPIRE实现简单令牌桶 - 日志里埋点统计
bf.exists == false的请求来源 IP 和 User-Agent，快速识别扫描行为 - 不要单独依赖布隆过滤器——它只是第一道筛子，后面还得有空值缓存兜底、互斥锁防击穿、TTL 随机化防雪崩
真正难的不是接入布隆过滤器，而是持续维护它的数据一致性：ID 池扩容、灰度发布、DB 分库分表后的多源合并、离线任务失败重试……这些地方一旦断链，布隆就从守门员变成摆设。
