布隆过滤器必须部署在风控网关入口，而非redis之后；需前置参数校验、统一key拼接规则、按全量上限初始化、启动时预热、空值缓存须频控+随机ttl、实例须单例并定时重建。
布隆过滤器必须插在风控网关入口，不能放在Redis之后
金融风控系统里，非法穿透请求往往带着伪造的交易ID、用户手机号或设备指纹，目标明确、并发极高。一旦让这类请求打到Redis集群，哪怕没命中，也会消耗连接池、序列化开销和分片路由成本——对毫秒级响应的风控链路来说，0.5ms的冗余延迟都可能影响决策。所以bloom.contains(key)这行代码必须出现在网关层解析完参数后的第一行，而不是在redisTemplate.opsForValue().get(key)之后。典型错误是把布隆逻辑写在Service里，等缓存未命中才查，此时穿透早已发生。
key拼接规则必须和缓存完全一致，且需提前做格式校验
风控场景下，transaction:202609031722abc这种非法ID不能进布隆过滤器，更不该让它参与哈希计算。真实部署中要分两步走：
- 先用正则快速拦截明显非法值：
^txn_\d{14}[a-zA-Z0-9]{3,8}$（匹配标准交易号前缀+时间戳+随机码），不匹配直接返回400 Bad Request - 对通过校验的key，再按统一规则拼成布隆用的key，比如去掉前缀只留数字部分：
"txn:" + timestampPart，确保和Redis中SET txn:202609031722 1 EX 3600的key结构对齐 - 千万别混用：缓存里存
user:138****1234，布隆里却查138****1234，结果永远返回false
初始化参数必须按全量合法ID上限计算，不能依赖运行时add
金融系统主键增长稳定但不可预测，比如某支付通道日均新增50万交易号，一年就是1.8亿。布隆过滤器初始化时expectedInsertions至少设为2亿，errorRate控制在0.03（3%）。否则：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 设成1000万容量却硬塞2亿数据，误判率会从3%飙升到30%以上，大量真实交易被拦，触发人工复核风暴
- 靠
BF.ADD动态补数据无法应对冷启动——新服务上线第一天，攻击者用脚本轮询txn_2026090300000001到txn_2026090399999999，布隆还没来得及加载，数据库已雪崩 - 必须在应用启动时执行全量预热：
SELECT txn_id FROM transaction_log WHERE status = 'success' AND create_time > DATE_SUB(NOW(), INTERVAL 1 YEAR)，然后批量BF.MADD txn_filter txn_2026090300000001 txn_2026090300000002 ...
空值缓存必须带频控和随机TTL，否则反而放大风险
DB查不到的非法交易号，绝不能无差别SET txn:xxx "" EX 60。攻击者只要并发扫10万个无效号，Redis内存就爆了。实际做法是：
- 只对1分钟内重复≥5次的非法
txn_id才写空值缓存 - TTL设为
300 + random(0, 60)，避免集体过期引发二次穿透 - 空值内容固定用
"__INVALID__"，和业务返回的null或空字符串严格区分 - 布隆过滤器本身不存空值——它只登记DB确认存在的合法ID；空值缓存是兜底，不是主力
最易忽略的一点：布隆过滤器实例必须是进程单例，且后台要有定时任务每6小时全量重建。软注销的商户、停用的支付通道ID不会自动从布隆里消失，靠增量BF.ADD只会让误判率缓慢爬升，直到某天凌晨批量放行恶意请求。
