布隆过滤器是拦截恶意空请求的最有效手段，需前置部署于Redis查询之前，通过全量加载与增量同步维护合法ID集合，并配合参数调优、基础校验、限流及空值缓存形成完整防护体系。
布隆过滤器是目前最有效的恶意空请求拦截手段，它不查数据、只做“存在性预判”，能在请求触达 Redis 之前就 100% 拦下非法 key。
必须前置部署在缓存查询之前
布隆过滤器只有放在 Redis 查询链路的最前端才起作用。正确顺序是：
- 请求到达网关或业务入口
- 提取目标 key（如 user:123456789）
- 调用 BF.EXISTS user_ids key
- 返回 0 → 确定不存在 → 直接返回 404 或空响应，不走后续任何环节
- 返回 1 → 可能存在 → 继续查 Redis → 未命中再查 DB
若把它放在 Redis 之后（比如“查 Redis 失败后再去 BF 查”），穿透已经发生，数据库早已被刷爆。
初始化要全量加载 + 增量同步
布隆过滤器不是运行时自动学习的模型，它依赖初始快照和持续维护：
- 服务启动时，从 MySQL 或其他权威源全量拉取所有合法 ID（如全部 user_id），执行 BF.MADD user_ids id1 id2 ...
- 新增数据（如用户注册）成功后，必须同步调用 BF.ADD user_ids new_id
- 软删除或注销用户无法从布隆中移除，需配合空值缓存兜底：DB 返回空时，也写入短 TTL 空对象，覆盖误判窗口
漏掉新数据会导致新用户首次访问被误拒；不处理删除则已注销用户仍可被“查到”，逻辑上不严谨。
参数设置不能拍脑袋
布隆过滤器的两个核心参数强绑定：预估容量（capacity）和允许误判率（error_rate）。改一个，另一个自动变。
- 假设你有 5000 万活跃用户，要求误判率 ≤ 0.01%，那位数组大小会自动算出约 850MB 内存
- 若把 capacity 设成 100 万却硬塞 5000 万数据，误判率可能飙升至 20% 以上，大量合法请求被拦，业务直接报错
- RedisBloom 中建 filter 必须用 BF.RESERVE user_ids 0.01 50000000，不能靠第一次 BF.ADD 自动创建（会阻塞首请求）
必须搭配基础校验与限流
布隆过滤器只防“根本不存在的 key”，不防“格式错误、越权、语义非法”的请求：
- 对 user_id 字段加正则校验：^[1-9]\d{7,15}$，拦截负数、超长数、字符串如 "admin"
- 对高频空响应路径（如 GET /user/{id}）做接口级限流，用 INCR + EXPIRE 实现每分钟最多 100 次空 key 查询
- 空值缓存仍要保留，设 60–120 秒 TTL，用于兜底布隆漏判和增量同步延迟
单靠布隆过滤器不能解决全部问题，它是第一道门禁，但门禁外还需岗哨和围栏。
