Redis布隆过滤器防缓存穿透详解

布隆过滤器是当前应对缓存穿透最可控、最有效的防御手段，但其威力完全依赖于正确落地——必须前置部署在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 分库分表后的多源合并、离线任务失败重试……这些地方一旦断链，布隆就从守门员变成摆设。

今天关于《Redis布隆过滤器防缓存穿透详解》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！