布隆过滤器能挡住恶意攻击的无效id，因其可确定不存在：bf.exists返回0则100%不在数据集，直接拦截；它仅用位数组和哈希函数，内存远低于空值缓存，且防绕过。
布隆过滤器为什么能挡住恶意攻击的无效 ID
因为布隆过滤器在查询阶段具备「确定不存在」的能力：只要 BF.EXISTS 返回 0，该 key 就 100% 不在原始数据集中，根本不用查缓存、更不用碰数据库。恶意构造的随机 ID（如 user_id=9876543210）几乎必然落在布隆过滤器的「空槽位」上，直接被拦截。
它不存真实数据，只维护一个紧凑的位数组 + 多个哈希函数。1 亿有效用户，用标准误差率 0.1%，内存开销约 115MB；而如果用空值缓存，每个无效 ID 写一条 SET user:9876543210 "NULL" EX 60，100 万个无效请求就占掉几十 MB 内存，且无法区分真假——攻击者故意打散 key 前缀就能绕过 LRU 驱逐。
Redis 中布隆过滤器必须用 RedisBloom 模块吗
不是必须，但强烈建议。原生 Redis 不支持布隆过滤器，BF.ADD 和 BF.EXISTS 是 RedisBloom 模块提供的命令，需手动加载：
- Linux 下启动 Redis 时加参数：
--loadmodule /path/to/redisbloom.so - Docker 启动示例：
docker run -p 6379:6379 --rm redis:7.2-alpine redis-server --loadmodule /usr/lib/redis/modules/redisbloom.so - Spring Boot 项目中若用
RedissonClient，则依赖redisson-spring-boot-starter并配置redisson.yaml，无需额外加载模块
自己用 BitSet 在应用层实现虽可行，但无法共享状态——多实例部署时各节点布隆过滤器不同步，攻击请求打到不同节点仍会穿透到 DB。
布隆过滤器初始化时漏掉新写入的数据怎么办
这是最常被忽略的运维盲点。布隆过滤器是静态快照，启动时从 DB 全量加载用户 ID 到 user_ids 过滤器后，后续新增的用户（如注册流程）不会自动进过滤器，导致新用户首次查询被误判为「不存在」，触发缓存穿透。
必须补上实时同步机制：
- 注册成功后，同步调用
BF.ADD user_ids <new_user_id></new_user_id> - 使用 Canal / Debezium 监听 MySQL binlog，将 INSERT 到
user表的主键自动投递到 RedisBloom - 避免用定时任务「每分钟全量重建」——期间有窗口期，且对大表压力大
注意：RedisBloom 的 BF.RESERVE 要提前规划好容量。例如预估 2000 万用户，误差率设为 0.01%，应执行：BF.RESERVE user_ids 0.01 20000000。运行中扩容只能重建，不能动态 resize。
为什么不能只靠布隆过滤器，还得配空值缓存
布隆过滤器存在「假阳性」：BF.EXISTS 返回 1 只表示「可能存在」，仍需查缓存或 DB。但如果此时 DB 真的没有这条记录（比如逻辑删除未同步、ID 范围错配），这次查询还是会穿透到 DB —— 这就是布隆过滤器防不住的漏网之鱼。
所以生产环境必须组合使用：
- 先查
BF.EXISTS user_ids <id></id>，返回0→ 直接返回 404 - 返回
1→ 查GET user:<id></id>，命中则返回 - 未命中 → 查 DB，若 DB 也无结果 → 写
SET user:<id> "NULL" EX 60</id>
这个双层防护里，布隆过滤器挡掉 99%+ 的恶意扫描流量，空值缓存兜底处理那不到 1% 的哈希冲突或数据不一致场景。两者缺一，都算没真正解决缓存穿透。
