rbloomfilter需预设容量和误判率且不可变，依赖redis加载redisbloom模块，否则操作抛redisexception；初始化参数expectedinsertions应按总预计量设置，falseprobability推荐0.01；add()恒返true，contains()返回false表示绝对不存在，true表示可能存在；无remove方法，缓存穿透防护需严格保证db写→缓存set→bloom add顺序。
直接用 RBloomFilter 就能解决大部分数据过滤场景，但必须提前设好容量和误判率，否则上线后无法调整、查不到数据还报错。
为什么不能直接 new RBloomFilter()？
RBloomFilter 是 Redisson 对 RedisBloom 模块的封装，底层依赖 Redis 服务端加载了 redisbloom 模块（不是原生 Redis 自带）。如果 Redis 没装这个模块，tryInit() 会静默失败，后续 add() 或 contains() 全部抛 org.redisson.client.RedisException，错误信息类似 ERR unknown command 'BF.ADD'。
- 确认 Redis 是否支持布隆过滤器：连上 Redis CLI，执行
BF.INFO test，返回(error) ERR unknown command就说明没装模块 - Linux 下安装 redisbloom：编译
redisbloom.so，在redis.conf中加loadmodule /path/to/redisbloom.so，重启 Redis - Spring Boot 启动时检查模块可用性：可在
BloomFilterUtil初始化前调用redissonClient.getNodesGroup().ping()+ 手动发BF.RESERVE命令试探
RBloomFilter 初始化参数怎么选？
初始化时传的两个参数 —— expectedInsertions 和 falseProbability —— 决定了位数组大小和哈希轮数，一旦写入数据就不可更改。设小了，误判率飙升；设大了，浪费 Redis 内存（且无法回收）。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
expectedInsertions不是“最大值”，而是“预计总插入量”。比如每天新增 10 万用户 ID，要支撑 30 天，就填3_000_000，别填 10 万 -
falseProbability推荐 0.01（1%）起步，0.001（0.1%）需多约 50% 内存。0.0001 以下基本不现实，位图膨胀太快 - 实际内存占用 ≈
-expectedInsertions * ln(falseProbability) / (ln(2)^2)字节，可用redis-cli memory usage bloom-key验证
add() 和 contains() 的行为边界在哪？
RBloomFilter.add() 总是返回 true（即使已存在），contains() 返回 false 表示“绝对不存在”，返回 true 表示“可能存在”——这是布隆过滤器的本质，不是 bug。
- 不能靠
add()返回值判断是否首次插入；要判断“是否已处理”，得组合业务逻辑（比如先contains()，再add()+ 执行业务） -
contains()在 Redis 节点故障或网络超时时可能抛异常，不能当纯布尔函数用；建议外层加 try-catch，异常时走降级逻辑（如直查 DB） - 没有
remove()方法。真需要删除，请换 Counting Bloom Filter 或改用 HyperLogLog + 白名单兜底
缓存穿透防护中容易漏掉的关键点
布隆过滤器挡不住“刚写入还没进过滤器”的请求，也挡不住“过滤器里有但缓存已过期”的请求，这两类都会打到 DB。
- 写操作必须严格遵循：DB 写成功 → 缓存 set →
bloomFilter.add()。顺序颠倒或缺少任一环，就会漏判 - 缓存失效时，不要删布隆过滤器里的 key（根本删不了），而应在更新缓存后同步
add()新值 - 对热点 key，布隆过滤器本身也可能成瓶颈；可考虑按业务维度分片（如
user_bloom_001、user_bloom_002）分散压力
真正难的不是调通 API，而是把容量预估、模块依赖、异常路径、与缓存/DB 的协同节奏全理清楚——少一个环节，线上就可能突然开始漏过滤。
