布隆过滤器必须前置部署于缓存层之前，作为第一道硬隔离防线；正确链路为请求→网关→bf.exists→存在才放行至redis→db，若置于缓存之后则完全失效。
布隆过滤器必须前置在缓存层之前
布隆过滤器不是可选的“锦上添花”，而是防御恶意穿透攻击的第一道硬隔离。它必须部署在请求进入 Redis 之前，否则所有无效请求仍会打到 Redis 实例，造成不必要的网络开销和内存压力。
常见错误是把 BF.EXISTS 放在缓存查询之后——这等于先让请求穿过网关、走完一次 Redis GET、再判断是否存在，完全失去拦截意义。
- 正确链路：客户端 → 网关/接入层 →
BF.EXISTS→ 存在才放行 → Redis → DB - 误判率要控制在可接受范围（如 0.1%），用
BF.RESERVE初始化时需预估总量，避免扩容失败导致误判飙升 - PHP 用
Predis、Java 用RedisBloom客户端，别自己手写哈希逻辑——位数组越界或哈希函数不一致会导致全量漏判
空值缓存不能无差别设置 TTL
对数据库返回 null 的 key 直接塞 setex(key, 60, "NULL") 是最常见也最危险的做法。攻击者只要轮询 100 万个无效 ID，就能在 Redis 中堆积 100 万条短期键，吃光内存。
真实业务中必须引入两个关键控制：
- 只对高频重复出现的无效 key 缓存空值（比如同一
user_id在 1 分钟内被请求 ≥3 次才触发） - TTL 必须带随机扰动：
setex(key, 300 + random(0, 60), "NULL")，防止大量空值在同一秒集体过期引发二次穿透 - 空值标记要用统一常量（如
"__EMPTY__"），避免和真实业务数据中的空字符串混淆
黑名单机制要区分冷热无效 key
单纯靠布隆过滤器 + 空值缓存，无法应对“新生成的无效 ID”攻击（比如攻击者持续生成 UUID 类似字符串）。这时需要运行时动态维护黑名单，但必须分层处理。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
冷黑名单（长期有效）：从数据库全量导出合法 ID 集合，构建布隆过滤器；
热黑名单（短期滚动）：用 Redis 的 HyperLogLog 统计单位时间内高频无效请求的前缀（如 item_ 后跟非数字字符），再用 SET 存储确认恶意的完整 key。
- 不要用
KEYS *扫描匹配，会阻塞 Redis 主线程 - 热黑名单清理必须用
EXPIRE而非定时任务删除，否则高并发下可能漏删 - 前端传参含明显非法模式（如
id=-1、id=abc）应在 API 网关直接400拦截，不进后端
布隆过滤器更新不能依赖定时同步
布隆过滤器一旦初始化，就默认认为集合静态不变。但业务中用户注册、商品上架等操作会实时新增合法 key，如果只靠每天凌晨全量重建，白天就会产生大量“真存在却被判不存在”的漏判。
生产环境必须支持增量更新：
- 写 DB 成功后，立即执行
BF.ADD，且需保证幂等（BF.ADD本身幂等，但网络重试可能导致重复调用） - 使用 pipeline 批量提交，避免单 key 单 round-trip 带来延迟放大
- 若用 Redis Cluster，确保布隆过滤器 key 的 slot 和对应业务 key 一致，否则跨节点查询失效
真正难的是布隆过滤器与业务数据的一致性边界——它永远只能是“大概率存在”，所以任何强一致性场景（比如支付订单号校验）都不能只依赖它，必须保留兜底的 DB 查询路径。
