布隆过滤器不能直接用于Redis多实例集群，因Redis Cluster按slot分片导致同名过滤器被路由至不同节点，bf.add/bf.exists仅作用于本地实例，无法跨节点同步状态，造成插入与查询不一致、漏判且不可恢复。
Redis布隆过滤器为什么不能直接用于多实例集群？
因为 Redis 原生的 bf.add、bf.exists 命令操作的是单个 Redis 实例上的位数组，而 Redis Cluster 模式下 key 会按 slot 分片到不同节点——同一个布隆过滤器名（如 bloom:user）可能被哈希到不同节点，导致插入和查询落在不同实例上，数据完全不一致。
更关键的是：bf.reserve 创建的过滤器是本地内存结构，无法跨节点广播或同步状态。你往节点 A 插入了 10 万个用户 ID，节点 B 的同名过滤器仍是空的，查询必然漏判。
RedisBloom 在集群模式下的实际行为
RedisBloom 模块本身**不自动支持集群拓扑感知**。即使你用 redis-cli -c 连接集群并执行 BF.ADD bloom:user u123，客户端会把 bloom:user 按 CRC16 算出 slot，路由到某一个节点；后续所有对该 key 的操作都只能命中该节点——这本质上退化成了「单点布隆过滤器 + 客户端路由」，不是真正意义上的分布式布隆过滤器。
这意味着：
- 你必须确保所有对同一逻辑集合的操作，都使用**相同 key 名**且不带 hash tag（如
{bloom:user}），否则会被打散 - 一旦该节点宕机，整个过滤器失效，且无法从其他节点恢复
- 横向扩容时，旧过滤器无法自动拆分或迁移，只能重建
生产环境可行的同步方案
真正的分布式布隆过滤器不是靠 Redis 自动同步，而是靠外部机制保证各节点过滤器内容一致。常用做法有：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
— 使用统一中心化布隆过滤器服务（推荐）：部署独立的布隆过滤器服务（如基于 RedisBloom 的单节点 + 高可用主从），所有业务服务统一调用它，避免在每个 Redis 实例上维护副本。
— 全量重推 + 版本号控制：通过消息队列（如 Kafka）或 CDC 工具（如 Canal）监听数据库增删事件，生成全量或增量快照，定期推送到所有 Redis 节点并执行 BF.LOADCHUNK 加载二进制位图；配合版本号（如时间戳或 sequence）防止乱序覆盖。
— 应用层双写兜底：写数据库的同时，异步调用 BF.ADD 到所有集群节点（需幂等设计）；但要注意网络分区时的写入不一致风险，必须搭配定时校验任务。
误判率与容量配置在集群中更难控制
单机布隆过滤器可通过 BF.RESERVE bloom:user 0.01 1000000 预设误差率和初始容量，但在集群场景下，如果不同节点使用不同参数创建同名过滤器（比如有的设 0.01，有的设 0.001），会导致误判率不可预测，且 BF.INFO 返回的结果只反映本地状态，无法聚合。
所以必须强制所有节点使用完全一致的 capacity 和 error_rate 参数，并在初始化阶段做一致性检查——这点容易被忽略，但直接影响线上缓存穿透防护效果。
