*Redis BF.MEXISTS 命令
BF.MEXISTS 批量检查多个元素是否可能存在于 Bloom Filter 中。
*语法
BF.MEXISTS key item [item ...]
*参数说明
| 参数 | 类型 | 必填 | 说明 |
|---|---|---|---|
| key | String | 是 | Bloom Filter 的键名 |
| item | String / Bytes | 是 | 要检查的元素，可指定多个 |
*返回值
返回 Integer 数组，每个元素对应一个输入 item： - 1：该元素可能存在于过滤器中（存在假阳性可能） - 0：该元素一定不存在于过滤器中 - Error：键存在但非 Bloom Filter 类型，或参数错误
*时间复杂度
O(n × k)，n 为 item 数量，k 为哈希函数数量。
*示例
*基本用法
> BF.RESERVE myfilter 0.01 1000
OK
> BF.MADD myfilter a b c
1) (integer) 1
2) (integer) 1
3) (integer) 1
> BF.MEXISTS myfilter a d e
1) (integer) 1
2) (integer) 0
3) (integer) 0
*缓存穿透防护批量检查
> BF.MEXISTS user_filter user:1001 user:1002 user:9999
1) (integer) 1
2) (integer) 1
3) (integer) 0
*键不存在
> BF.MEXISTS nonexist x y
1) (integer) 0
2) (integer) 0
*常见错误
| 错误 | 原因 | 解决 |
|---|---|---|
| WRONGTYPE | key 已存在且不是 Bloom Filter 类型 | 确认 key 对应的数据结构 |
| ERR wrong number of arguments | 未提供任何 item | 至少提供一个 item 参数 |
*最佳实践
- 批量检查场景优先使用 BF.MEXISTS 替代多次 BF.EXISTS，减少 RTT
- 返回 0 的元素可直接过滤（一定不存在），返回 1 的元素需进一步查询底层存储确认
- 单次批量元素数量建议控制在 1000 以内
*FAQ
Q1: BF.MEXISTS 和多次调用 BF.EXISTS 效果一样吗？ A: 逻辑结果一致，但 BF.MEXISTS 只需一次网络往返，性能更好。
Q2: 返回 1 的元素还需要查数据库吗？ A: 需要。Bloom Filter 返回 1 仅表示"可能存在"，存在假阳性概率，必须查数据库确认。返回 0 则可直接跳过数据库查询。
Q3: 键不存在时返回什么？ A: 返回全 0 数组，表示所有元素都不存在。