RedisBloom插件不可在Redis集群中协同工作，必须使用独立单节点部署；所有请求需先经该节点BF.EXISTS校验，再路由至集群查缓存或DB。
RedisBloom插件必须在集群模式外独立部署
Redis 集群本身不支持 RedisBloom 插件协同工作。CRC16 分片机制导致每个节点的 bloom 数据无法共享，如果强行在各节点分别加载插件，BF.ADD 写入 A 节点，BF.EXISTS 查询却落到 B 节点，就会返回 false——这直接破坏布隆过滤器“不存在一定不存在”的核心保证。
正确做法是：用单节点 Redis 实例专供布隆过滤器，所有请求先走这个节点做 BF.EXISTS 校验；校验通过后再路由到真正的 Redis 集群查缓存或 DB。这个单节点无需高可用，但必须禁用 maxmemory 策略（避免 LRU 清掉位图），并配置 save "" 关闭 RDB 持久化（布隆数据冷启动预热即可，不依赖磁盘恢复）。
BF.RESERVE 必须显式指定 size 和 error_rate
创建布隆过滤器时不能依赖默认参数。未指定 error_rate 会导致误判率高达 0.05（5%），大量合法请求被误拦；未指定 size 则 RedisBloom 自动按 100 个元素初始化，后续扩容触发 BF.MADD 性能断崖下跌。
生产建议值：
- 预期容量
size = 1.2 × 合法 ID 总量（留 20% 余量） - 误判率
error_rate = 0.01（1%）——再低内存翻倍，收益趋近于零 - 命令示例：
BF.RESERVE user_bf 0.01 1200000
冷启动必须全量预热，且需绕过应用层逻辑
上线首小时若没预热，所有请求都会被 BF.EXISTS 返回 0，等同于全部拦截。不能靠“第一次查 DB 成功后补 BF.ADD”，因为恶意流量会卡在预热完成前打垮 DB。
预热必须离线执行：
- 从主库导出全量
user_id、sku_id等关键字段，生成文本文件 - 用
redis-cli --pipe批量执行：BF.ADD user_bf "123"（注意引号防空格截断） - 预热脚本要加失败重试，单条失败不中断整体流程
预热完成后，用 BF.INFO user_bf 核对 Size 和 Items inserted 是否匹配，差值超过 0.1% 就得重来。
Java 客户端调用 BF.EXISTS 时必须处理连接异常和空响应
Spring Boot 项目里用 Lettuce 连接 RedisBloom，常见坑是把 BF.EXISTS 当普通命令用 execute()，结果遇到网络抖动直接抛 RedisCommandTimeoutException，整个请求失败——这等于把布隆过滤器变成了单点故障。
安全写法：
- 设置超时：Lettuce
timeoutCommands配置为 ≤ 10ms（布隆查询本应微秒级） - 降级策略：捕获
RedisException后默认放行（return true），宁可多查一次缓存，也不能阻断正常流量 - 空响应兜底：
BF.EXISTS返回null或0L时，统一按“不存在”处理，避免 NPE
最易被忽略的一点：预热脚本跑完不代表线上生效。RedisBloom 的位图结构在不同版本间有兼容性差异，Redis 8.2.3 修复了 CVE-2025-62507 后，旧版预热数据可能被拒绝读取——上线前务必在同版本环境验证 BF.INFO 输出是否正常。
