布隆过滤器必须前置部署在客户端或网关层，因Redis集群分片导致布隆过滤器无法跨节点共享，各节点独立维护会破坏“不存在一定不存在”的保证，且Redis原生不支持、插件不兼容集群模式。
布隆过滤器必须放在请求进入 Redis 集群之前，也就是在客户端或网关层做判断，不能依赖 Redis 集群本身来执行过滤。
为什么必须前置部署
Redis 集群按 key 的 CRC16 值自动分片，同一个布隆过滤器无法跨节点共享。如果每个节点各自维护一份，不仅误判率失控，还会因路由不一致导致漏判——比如 key 在 A 节点注册，但请求被路由到 B 节点查询，结果返回“不存在”，实际该 key 是合法的，这就违背了布隆过滤器“不存在一定不存在”的核心保证。
Redis 本身也不原生支持布隆逻辑；即使装了 redisbloom 插件，它也只是单节点扩展，无法在集群模式下协同工作。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
关键落地前提
- 实例必须进程内共享：不能每次请求都 new 一个布隆过滤器对象，得用单例、静态变量或 Spring 容器托管，否则容量和哈希参数失效，误判率完全不可控
- 初始化要算准两个参数：根据预估合法 key 总量（如 1 亿用户 ID）和可接受误判率（如 0.1%），用标准公式反推位数组长度和哈希函数个数；硬塞超量数据会导致误判率飙升，大量真实请求被拦
- 必须定期全量重建：布隆过滤器不支持删除，软删用户、下架商品等变更无法实时剔除；靠 BF.ADD 增量更新会累积脏数据，所以得用后台任务定时拉取最新合法 ID 全量重建
拦截点与校验流程
典型链路是 client → gateway → Redis cluster。防御必须卡在 gateway 或 client 端：
- 网关收到请求后，先拼出原始缓存 key（如 /user?id=9999999999 → user:9999999999）
- 调用本地布隆过滤器 bloom.contains(key)
- 返回 false → 直接响应 404，不转发；返回 true → 继续走正常缓存逻辑（查 Redis → 未命中查 DB → 写空值缓存）
- DB 查无结果时，要把该 key 补加进布隆过滤器，否则下次同样请求仍会穿透
不能只靠布隆过滤器
它只防“根本不存在的 key”，挡不住格式非法、越权或语义错误的请求：
- 对 user_id 加正则校验：^[1-9]\d{7,15}$，直接拦截负数、超长数、“admin”这类字符串
- 对高频空响应路径（如 GET /user/{id} 返回 404）做 QPS 限流，用 Redis INCR + EXPIRE 实现简单令牌桶
- 空值缓存仍需保留：DB 查不到时写入 short TTL 的 "NULL"，作为布隆过滤器的兜底补充，防止重建间隙被攻击
