布隆过滤器必须在客户端或代理层实现，因Redis集群不支持原生命令且分片机制导致全局结构无法协同；需进程内共享实例、预估参数并定期重建，拦截点须在gateway或client端前置校验。
布隆过滤器为什么必须在客户端或代理层做，不能放在Redis集群里
Redis本身不支持布隆过滤器的原生写入/查询逻辑——BF.ADD、BF.EXISTS 这些命令来自 redisbloom 模块，它只是插件，不是集群内置能力。更关键的是：Redis集群分片基于 key 的 CRC16 值路由，而布隆过滤器是一个全局数据结构，必须覆盖所有可能的非法 key；如果每个节点各自维护一份，误判率会失控，且无法协同更新。
所以实际部署时，布隆过滤器只能前置——要么嵌在业务代码（客户端），要么塞进统一网关或 Redis 代理（如 Twemproxy + 自定义 filter，或使用 Redis Proxy 支持 Lua 扩展的方案）。
客户端集成布隆过滤器的三个硬性前提
不是加个 guava 或 pybloom-live 就能用，必须满足：
- 布隆过滤器实例必须是进程内共享的（比如单例或静态变量），不能每次请求 new 一个，否则容量和误判率完全不可控
- 初始化时要预估总量
n和期望误判率p，用公式算出位数组长度m和哈希函数个数k；例如 1000 万 key、误判率控制在 0.1%，m ≈ 142MB，不是随便设个 1MB 就行 - 必须有后台线程定期全量重建——因为非法 key 集合会变，而布隆过滤器不支持删除；靠
BF.MADD增量加载容易累积脏数据，最终误判率飘高
集群环境下缓存穿透请求的真实路径和拦截点
典型链路是：client → gateway → redis cluster。防御必须卡在 gateway 或 client，否则请求已经打到集群某分片节点，就失去了“提前拒绝”的意义。常见错误是：在业务代码里先查 Redis，没命中再查 DB，然后才想“加个布隆过滤器”，这已经晚了。
正确做法是两层校验：
- 第一层：gateway 根据请求 path + query 参数拼出原始 key（比如
/user?id=9999999999→user:9999999999），调用本地布隆过滤器bloom.contains(key) - 第二层：若
contains返回false，直接 404；若返回true，才转发请求——注意，true只代表“可能合法”，仍需走正常缓存逻辑
别忘了对空值也做布隆登记：DB 查不到时，把 key 加进布隆过滤器（bloom.add(key)），否则重复穿透。
用 RedisBloom 模块做兜底校验反而会放大风险
有人想“既然集群装了 redisbloom，干脆让每个节点都存一份布隆过滤器”，这会导致严重问题：
- key 路由到哪个节点不确定，
BF.EXISTS bloom_key user:123可能打到 A 节点，但该 key 实际在 B 节点注册过，结果漏判 - 集群扩缩容触发 slot 迁移，布隆过滤器数据不会自动同步，旧节点残留、新节点为空，误判率瞬间飙升
-
BF.RESERVE创建过滤器时指定的capacity是硬上限，超了会报错(error) ERR not enough space，而集群里没人监听这个错误
真正安全的做法只有一种：布隆过滤器离业务最近，且与缓存读写生命周期解耦。它不依赖 Redis 集群状态，也不参与分片逻辑——这点最容易被忽略。
