布隆过滤器必须部署在请求最前端（如网关层或Controller入口），在提取key后、调用redis.get()前执行BF.EXISTS，全量初始化+增量同步，严格统一key格式，按真实数据量显式配置capacity与error_rate，并配合参数校验和限流使用。
布隆过滤器不是“加个依赖就能用”的组件，它必须嵌在请求最前端、配合数据一致性与参数调优，才能真正拦住恶意空请求。核心不在 Redis 本身，而在部署位置和协同逻辑。
必须放在 Redis 查询之前，且靠近入口
布隆过滤器只有在 提取 key 后、调用 redis.get() 前 执行，才算有效。常见错误是把它放在缓存未命中之后——此时请求已穿透到 DB，防御失效。
- 推荐位置：网关层（如 Spring Cloud Gateway 的 GlobalFilter）、Controller 入口或 Service 方法开头
- 不推荐位置：DAO 层、RedisTemplate 封装内部、或“查完 Redis 再判断”
- 若用 RedisBloom 模块，BF.EXISTS 必须在 Jedis/Redisson 调用 get() 之前执行
初始化要全量加载 + 增量同步，不能靠运行时补漏
布隆过滤器不会自动学习，它只认你喂进去的数据。漏掉 ID，新用户就 404；多塞 ID，误判率飙升。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 启动时从 MySQL 全量拉取合法主键（如 SELECT id FROM user WHERE status = 1），统一格式后批量 BF.MADD
- 用户注册成功后，立刻 BF.ADD；软删除不删布隆项，但需配合空值缓存兜底
- 缓存 key 是 "user:123"，布隆里也存 "user:123"，而不是裸数字 123 —— 类型和格式必须严格一致
参数设置要按真实数据量算，不能默认或拍脑袋
容量（capacity）和误判率（error_rate）强绑定。设小了，5000 万用户可能误判 15%；设大了，内存暴涨却无收益。
立即学习“Java免费学习笔记（深入）”；
- 用 BF.RESERVE 显式创建：BF.RESERVE user_ids 0.001 50000000（5000 万条，误判率 ≤ 0.1%）
- 避免用第一次 BF.ADD 自动建 filter，会阻塞首请求且参数不可控
- 位数组大小由算法自动推导，例如 5000 万 + 0.01%，约需 850MB 内存，需评估单机承载力
必须搭配基础校验和限流，布隆不是万能门禁
布隆只回答“这个 key 绝对不存在吗？”，它不管 ID 是负数、超长、含字母还是越权访问。
- 对 user_id 加正则校验：^[1-9]\d{7,15}$，拦截 -1、abc、12345678901234567890 等非法格式
- 对高频空响应路径限流：INCR + EXPIRE 实现每分钟最多 100 次空 key 查询
- 空值缓存仍要保留：DB 返回 null 时写入 "NULL" 并设 60–120 秒 TTL，覆盖布隆漏判和同步延迟窗口
