Redis BF.MEXISTS批量判断结果怎样对应输入项

Redis 的 BF.MEXISTS 会一次检查多个元素，返回一个与输入项等长的布尔数组。对应关系不需要额外的 ID：第 1 个返回值对应第 1 个输入项，第 2 个返回值对应第 2 个输入项，依次按位置配对。真正容易出错的地方有两个：数组下标被业务代码打乱，以及把 true 理解成“数据库里一定存在”。

官方地址：https://redis.io/docs/latest/operate/oss_and_stack/stack-with-enterprise/bloom/commands/

把输入集合先固定成有序切片，再用同一个下标读取返回数组，就能稳定完成映射；但 Bloom Filter 的 true 只表示“可能存在”，需要强一致结论时还要回查主数据源。

BF.MEXISTS 的返回值按位置对应输入项

命令的形态可以记成 BF.MEXISTS key item [item ...]。Redis 只返回判断结果数组，不返回输入字符串本身。因此，客户端必须保留发给 Redis 的原始顺序：

# 先准备有稳定顺序的输入项，再把同一顺序传给 BF.MEXISTS
BF.MEXISTS users:seen alice bob carol dave
# 返回数组的第 0、1、2、3 项分别对应 alice、bob、carol、dave

例如返回 [1, 0, 1, 0]，含义是 alice 和 carol 可能已经加入过滤器，bob 和 dave 确定没有被过滤器判定为存在。这里的“可能”是 Bloom Filter 的语义，不能省略。

客户端代码要保留原始切片和下标

在 Go 客户端中，可以把输入项和 Redis 返回值放入同一个循环，使用下标生成业务侧的映射。下面用通用的 Do 调用表达命令参数，避免把某个客户端封装方法误当成 Redis 命令本身：

package main

import (
    "context"
    "fmt"

    "github.com/redis/go-redis/v9"
)

func checkUsers(ctx context.Context, rdb *redis.Client, users []string) ([]string, error) {
    args := make([]interface{}, 0, len(users)+2)
    args = append(args, "BF.MEXISTS", "users:seen")
    for _, user := range users {
        // 参数顺序必须与 users 保持一致，返回数组才可按下标配对。
        args = append(args, user)
    }

    raw, err := rdb.Do(ctx, args...).Result()
    if err != nil {
        // 命令失败时不要把部分结果当成完整判断，直接交给上层重试或降级。
        return nil, err
    }
    values, ok := raw.([]interface{})
    if !ok || len(values) != len(users) {
        return nil, fmt.Errorf("BF.MEXISTS 返回数量异常: got=%T len=%d want=%d", raw, len(values), len(users))
    }

    maybeSeen := make([]string, 0)
    for i, value := range values {
        // 这里的 1 只代表可能存在；确定不存在的项不会进入回查集合。
        if n, ok := value.(int64); ok && n == 1 {
            maybeSeen = append(maybeSeen, users[i])
        }
    }
    return maybeSeen, nil
}

关键不是使用哪一种客户端，而是同时保留 users 和返回数组的位次。若业务层先把用户去重、排序或异步拆批，却没有同步保存每个结果对应的原始项，最后就会出现“结果数量正确但对象对应错误”。

true 结果为什么还要回查主数据源

Bloom Filter 允许误判：false 可以作为“确定不存在”的快速结论；true 只能作为“可能存在”的候选信号。这个方向不能反过来使用，否则新用户可能因为误判而被错误拒绝。

适合的业务分层是：先用 BF.MEXISTS 从大批输入中筛出可能存在项，再把这部分项交给数据库、主键集合或其他权威数据源确认。不要为了省掉回查而把布隆过滤器当成完整集合。

重复项、空输入和异常返回怎么处理

重复项不会改变“按位置对应”的规则。例如输入是 ["alice", "alice", "bob"]，返回数组也必须按三个位置解释；是否在业务层去重，要看调用方是否需要保留原始行号。批量导入、风控候选或日志关联通常应保留位次，去重后的结果再反向展开。

空输入应在客户端提前决定策略：如果业务允许，直接返回空结果并不发送命令；如果必须调用，则要注意不同客户端对“没有可变参数”的编码方式可能不同。Redis 命令失败、返回类型异常或返回数量不一致时，也不能把已有片段当成成功结果。

// 下面的映射逻辑保留原始行号，便于把可能存在的项交给主数据源复核。
type Candidate struct {
    Row  int
    Item string
}

func pair(items []string, flags []bool) ([]Candidate, error) {
    if len(items) != len(flags) {
        return nil, fmt.Errorf("结果与输入未对齐: items=%d flags=%d", len(items), len(flags))
    }
    out := make([]Candidate, 0)
    for i, mayExist := range flags {
        // true 只进入候选列表，后续仍需由权威数据源确认。
        if mayExist {
            out = append(out, Candidate{Row: i, Item: items[i]})
        }
    }
    return out, nil
}

使用 BF.MEXISTS 前的速查

最后再回答两个常见问题：BF.MEXISTS 不会为每项返回原文，所以映射责任在调用方；它也不适合替代数据库唯一性约束。把“位置对齐”和“概率语义”同时保留下来，批量判断才既快又不会误导后续业务。