必须用Lua脚本封装布隆过滤器操作，因为其原子性可确保k个哈希位的SETBIT/GETBIT不可分割；且所有哈希计算须在Lua内完成，避免客户端哈希不一致导致映射错乱。
为什么不能直接用 SETBIT + GETBIT 手动实现布隆过滤器
Redis 原生不提供布隆过滤器命令，有人会尝试用 SETBIT 和 GETBIT 模拟位数组，再自己算哈希、设位——这在单线程下看似可行，但一到并发就出问题：多个客户端同时对同一个 key 执行多次 SETBIT，无法保证所有哈希位原子性地“全写入或全不写”。漏掉任意一位，后续 GETBIT 判断就可能误判为“不存在”，破坏布隆过滤器的“不漏判”特性。
更麻烦的是，手动实现还要自己管理容量扩容、哈希函数数量、误判率控制，实际落地时极易因位图越界（ERR bit offset is not an integer or out of range）或哈希冲突堆积导致误判率远超预期。
所以，绕过 Lua 直接用客户端拼逻辑，不是“能不能做”，而是“做了也难稳”。
为什么必须用 Lua 脚本封装布隆过滤器操作
Lua 脚本在 Redis 中以原子方式执行，整个脚本期间不会有其他命令插入。这对布隆过滤器最关键：添加元素需计算 k 个哈希值、对 k 个位执行 SETBIT；查询需对 k 个位执行 GETBIT 并 AND 判断——这两组操作都必须不可分割。
常见错误是把哈希计算放在客户端，只让 Lua 做位操作。这不行：不同客户端用不同语言/版本算哈希，结果不一致（比如 Python 的 hash() 在进程重启后变，Java 的 String.hashCode() 虽稳定但和 Redis Lua 的 redis.sha1hex() 不兼容），会导致同一元素在不同客户端被映射到不同位，彻底失效。
正确做法是：所有哈希计算、位索引推导、位操作，全部在 Lua 脚本内完成。示例如下（简化版 ADD）：
local key = KEYS[1]
local element = ARGV[1]
local m = tonumber(ARGV[2]) -- 位图总长度
local k = tonumber(ARGV[3]) -- 哈希函数个数
<p>for i = 1, k do
local h = redis.sha1hex(element .. i) -- 拼 salt 防止哈希退化
local idx = tonumber(string.sub(h, 1, 12), 16) % m
redis.call('SETBIT', key, idx, 1)
end
return 1注意：string.sub(h, 1, 12) 取前 12 位十六进制字符（≈48bit），转十进制后对 m 取模，避免大数溢出；i 作为 salt 确保 k 个哈希相互独立。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
如何避免 Lua 脚本触发 Redis 的 OOM 或慢日志
布隆过滤器的位图如果过大（比如 m > 100M bits ≈ 12MB），每次 SETBIT 都可能触发 Redis 内存重分配，而 Lua 脚本执行期间会阻塞主线程——一个大 key 的 ADD 就能让整个实例卡住几百毫秒。
实操建议：
- 预估容量：用公式
m = -n * ln(p) / (ln(2)^2)计算位图大小，其中n是预期元素数，p是目标误判率（如 0.01）；别盲目设 1GB 位图 - 拆分粒度：对超大规模场景，按时间窗口或业务维度分 key（如
bloom:order:202405），而非单 key 扛全量 - 禁用 EVALSHA：Lua 脚本尽量用
EVAL直传（避免EVALSHA命中失败后 fallback 的额外 round-trip），但要控制脚本长度（lua-time-limit默认 5s，超时会中断并返回错误BUSY Redis is busy running a script） - 监控
latency latest和slowlog get，重点看eval类型慢命令
为什么推荐用 RedisBloom 模块而不是手写 Lua
手写 Lua 能跑通，但生产环境要面对的问题远不止原子性：自动扩容（当元素数超限时动态扩展位图）、内存优化（roaring bitmap 压缩）、多精度支持（支持 COUNTING 布隆）、与 Redis Cluster 兼容性……这些全靠 Lua 很难稳健实现。
RedisBloom 模块（官方维护）已解决这些问题：BF.ADD / BF.EXISTS 原子、BF.RESERVE 支持指定 ERROR 和 SIZE、集群模式下 key hash tag 自动路由。它底层仍是 C 实现的位操作，性能比 Lua 高一个数量级。
如果你的 Redis 版本 ≥ 6.0 且能装模块，别犹豫——redis-cli --loadmodule ./redisbloom.so 启动后，直接用 BF.ADD myfilter "user:123"。手写 Lua 的唯一合理场景，是嵌入已有无法升级/加模块的旧系统，且数据规模可控（日增
真正容易被忽略的点是：布隆过滤器的“删除”能力。标准布隆不支持删除，RedisBloom 的 CF.ADD（Cuckoo Filter）可删但有踢出风险；而手写 Lua 若强行加 DELETE 逻辑，极易因并发导致状态不一致——这时候，与其硬刚，不如换思路：用带 TTL 的普通 key 做轻量缓存兜底。
