布隆过滤器在Redis中通过BF.EXISTS拦截无效key，将数据库QPS从1.8万降至87，缓存命中率超99.2%，需用RedisBloom模块（v2.4+）、预建filter、合理设capacity与error_rate，不可扩容，且须配合空值缓存兜底。
布隆过滤器在Redis中拦截无效key的实际效果
布隆过滤器在Redis里不是“查数据”，而是“挡请求”——它不存业务值，只回答“这个key大概率存不存在”。只要BF.EXISTS返回0，请求就该立刻终止，根本不会走到缓存或数据库层。
真实压测数据显示：在每秒2万次恶意ID查询（全为不存在的user:123456789类key）下，启用RedisBloom模块后，数据库QPS从1.8万降至87，缓存命中率稳定在99.2%以上。关键不是“快”，而是“稳”：它把穿透流量直接掐死在网关之后、缓存之前。
- 必须用
RedisBloom模块（v2.4+），原生Redis不支持布隆过滤器 -
BF.RESERVE要提前建好，不能等第一次BF.ADD时动态创建（否则首请求会阻塞） - 误判率设为
0.01（1%）时，实际线上误报约0.2~0.5%，但BF.EXISTS返回1后仍必须查一次缓存，不能直接放行
海量数据下布隆过滤器的内存与误判率权衡
布隆过滤器的内存占用和误判率由两个参数硬绑定：capacity（预估最大元素数）和error_rate（允许误判概率）。改一个，另一个就变——不是配置项，是数学约束。
比如你预计存1亿用户ID，要求误判率≤0.1%，那底层位数组长度会自动算出约1.44亿bit（≈17.6MB）。如果强行把capacity设成1000万却塞进1亿数据，误判率会飙升到30%以上，等于失效。
- 扩容不可行：布隆过滤器不支持动态扩容，超容必须重建新filter并重放历史数据
- 不要用
BF.MADD批量加冷数据来“凑满”capacity——冷数据长期不查，纯占位，反而抬高误判率 - 电商场景常见做法：按用户注册时间分片，每天建一个
bf:user_daily_20260406，过期自动丢弃
RedisBloom模块加载与生产环境避坑点
很多团队卡在第一步：模块根本没加载成功，却还在代码里调BF.ADD，结果报ERR unknown command，还以为是命令写错。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
验证是否生效，别只看redis-cli --version，要进redis执行MODULE LIST，确认输出里有name:bf。加载失败常见原因：
- Redis版本低于6.0（
RedisBloom最低要求6.0） - 启动时没加
--loadmodule /path/to/redisbloom.so，或redis.conf里漏了loadmodule /path/to/redisbloom.so - so文件架构不匹配：Mac M系列芯片需编译arm64版，x86_64版直接报
invalid ELF header - 容器部署时，宿主机挂载路径权限不足，Redis进程读不到so文件
为什么不能只靠SET key "NULL" EX 60防穿透
空值缓存看似简单，但在高并发+海量无效key场景下，它会从“防护”变成“负担”：
攻击者用脚本生成1000万个随机order:xxxxxx，每个都触发一次SET order:xxx "NULL" EX 60，60秒内Redis内存暴涨2GB，LRU开始疯狂驱逐有效缓存，连带导致真实用户请求也频繁击穿。
- 空值缓存适合低频无效请求（如用户手输错误ID），不适合自动化扫描或恶意构造
- 即使加了随机TTL（如
EX 30-90），也无法解决内存被无效key占满的问题 - 真正可靠的组合是：
布隆过滤器前置拦截 + 空值缓存兜底（仅对BF返回1且DB确认为空的key）
布隆过滤器的位数组不随key数量线性增长，而空值缓存的key数量和内存占用是严格正比的——这个差异在千万级无效请求面前，就是系统稳不稳的分水岭。
