Redis 6.0 不内置布隆过滤器，BF.ADD等命令需手动编译加载redisbloom模块；API网关须在请求到达前用BF.EXISTS预判存在性，结合全量初始化与合理BF.RESERVE参数避免误判或内存浪费。
Redis 6.0 本身不内置布隆过滤器，BLOOM 相关命令（如 BF.ADD、BF.EXISTS）需要额外加载 redisbloom 模块 —— 这是 API 网关层做缓存穿透拦截的前提，不是开箱即用的功能。
为什么不能直接在 Redis 6.0 默认安装里用 BF.EXISTS
Redis 6.0 原生不包含布隆过滤器实现。即使你看到文档提到 redisbloom 支持 Redis 6.0+，也必须手动编译并配置 loadmodule 才能启用：
-
redisbloom是一个独立的 Redis 模块，需下载源码后用make编译出rebloom.so - 启动 Redis 时必须显式加载：
redis-server --loadmodule /path/to/redisbloom.so，或写入redis.conf的loadmodule行 - 若跳过这步，执行
BF.ADD会报错：(error) ERR unknown command `BF.ADD`, with args beginning with: `user:1001` - Docker 部署更易踩坑：官方
redis:6.0镜像不含redisbloom，需自定义镜像或使用redislabs/rebloom:latest
API 网关层调用布隆过滤器的典型流程
网关（如 Kong、Spring Cloud Gateway、或自研 Nginx + Lua）应在请求抵达后端服务前完成「存在性预判」，而不是等请求打到 Redis 再查缓存：
- 对请求路径或参数提取唯一 key（例如
/api/user/123→ 提取123，拼成user_id:123） - 向 Redis 发起
BF.EXISTS bloom:user_ids user_id:123；返回0表示极大概率不存在，直接返回404或空响应 - 返回
1仅表示「可能存在的」，仍需走正常缓存逻辑（GET user:123→ miss 则查 DB → 回填） - 注意布隆过滤器只增不删，所以「误判为存在」是允许的，但「漏判为不存在」绝对不允许 —— 因此初始化阶段必须把全量有效 ID 一次性
BF.ADD进去
BF.RESERVE 参数设置不当会导致内存爆炸或误判率飙升
创建布隆过滤器时，BF.RESERVE 的两个关键参数直接影响效果和资源消耗：
-
capacity：预期最大元素数。设太小（如预估 100 万却只设 10 万），插入新元素后误判率会急剧上升；设太大则浪费内存 -
error_rate：期望误判率，例如0.01（1%）。值越小，底层位数组越大 ——error_rate=0.001比0.01多占约 4.8 倍内存 - 生产建议：按业务 ID 总量 × 1.2 设
capacity，error_rate控制在0.01～0.001之间；可用BF.INFO bloom:user_ids查看实际占用和当前元素数 - 别用默认参数：不指定
BF.RESERVE而直接BF.ADD，RedisBloom 会自动创建，但默认capacity=100、error_rate=0.01，完全不适合生产
布隆过滤器的「不可删除」特性决定了它不适合频繁变更 ID 集合的场景（比如用户秒级注销）；如果业务存在大量动态失效 ID，得搭配其他机制（如短时效的 SETNX 黑名单）来兜底。
