Redis 7.0 前无原生布隆过滤器，需依赖 redisbloom 模块或手动实现；云 Redis 通常未启用该模块，须先用 MODULE LIST 确认；手动实现依赖 SETBIT/GETBIT 与多哈希（推荐 fnv1a_64/murmur3），K 取 3–5，BIT_SIZE 需按预估总量与误判率反推，避免空间不足导致误判飙升。
Redis里没有现成的BLOOM命令，得自己搭
Redis 7.0 之前压根不支持原生布隆过滤器，官方模块 redisbloom 是后来加的扩展，不是默认内置。如果你用的是云 Redis（比如阿里云、腾讯云），大概率默认没开这个模块，连 BF.ADD 都会报 unknown command。别急着写业务逻辑，先确认模块是否加载：
- 连上 Redis 执行
MODULE LIST，看输出里有没有name:bf - 没有的话，要么换用支持 RedisBloom 的服务，要么退回到 Bitmap + 多哈希的手动实现
- 注意：手动实现没法动态扩容，误判率得在编码时就定死，改不了
手写布隆过滤器：用SETBIT + 多个哈希函数模拟
核心思路是把一个 key 映射成 k 个 bitmap 位置，全部置 1；查的时候，k 个位置全为 1 才认为“可能存在”。关键不在哈希有多强，而在分散性——推荐用 fnv1a_64 或 murmur3 这类快且均匀的哈希，别用 MD5 或 SHA1，太重还容易碰撞。
- 哈希后对 bitmap 总长度取模，比如
len = 1000000，那就hash % len - 用
SETBIT key offset 1设置位，用GETBIT key offset检查位 - 建议固定用 3–5 个哈希函数，太少误判高，太多写压力大，且 Redis 单次命令不能批量读多个 bit
- 示例片段（Python）：
offsets = [hash_func(key, i) % BIT_SIZE for i in range(K)]<br>pipe = redis.pipeline()<br>for offset in offsets:<br> pipe.setbit(KEY, offset, 1)<br>pipe.execute()
GETBIT 批量检查必须串行，性能比想象中差
Redis 没有类似 MGETBIT 的命令，查 k 个 bit 得发 k 次 GETBIT，哪怕走 pipeline，网络往返和 Redis 解析开销也明显。实测在 10k QPS 场景下，5 个哈希 → 5 次 GETBIT 容易打满 Redis 连接数或延迟飙升。
- 如果业务允许少量漏判（即该拦没拦），可降为 3 个哈希，减少 40% 查询压力
- 更稳的做法是：把 bitmap 存成一个
GET能拿下的紧凑字符串（比如 base64 编码的 bytes），客户端自己解出所有 bit —— 但要求 bitmap 不太大（建议 ≤ 1MB），否则拖慢主从同步 - 千万别在 Lua 脚本里循环调
redis.call('GETBIT', ...)，Lua 是单线程阻塞的，一个慢请求卡住整个实例
误判率控制不住？问题大概率出在BIT_SIZE和K没配平
理论误判率 ≈ (1 − e−k·n/m)k，其中 n 是已插入元素数，m 是总 bit 数，k 是哈希个数。很多人只调 k，忽略 m —— 实际上线前必须按预估总量反推 m。
- 例如：预计存 100 万 item，接受 1% 误判 → 查表或算得 m ≈ 9.6M bit（约 1.2MB），k = 7
- 如果硬用 1M bit 存 100 万，哪怕 k=10，误判率也会飙到 30%+，不是哈希不行，是空间不够
- bitmap 太大会让
SETBIT命令变慢（Redis 要 realloc 内存），建议单个 key 控制在 4MB 以内 - 线上务必监控
INFO memory中的used_memory_dataset，防止 bitmap 膨胀吃光内存
