Redis ZINTERCARD 怎样用交集数量判断多个有序集合是否匹配

如果业务只关心“几个候选集合里有多少成员同时出现”，不用先把交集写入新键再读取数量。Redis 的 ZINTERCARD 会直接返回多个有序集合的交集基数，最小匹配数量可以直接拿这个整数判断。

官方地址：https://redis.io/docs/latest/commands/zintercard/

实战中我会把查询分成两种：需要准确数量时使用 ZINTERCARD numkeys key...，只想判断“是否达到门槛”时才考虑追加 LIMIT。不要把达到上限的返回值误读成真实交集总数。

先把“匹配”定义成共同成员数量

比如一个推荐筛选场景里，candidate:skill-a 保存具备技能 A 的候选人，candidate:skill-b 保存具备技能 B 的候选人。两个集合的交集就是同时具备两项技能的人，但本文只需要交集数量，不需要生成一份新的有序集合。

# 准备两个有序集合；分数在本例中只是成员的排序分值
redis-cli ZADD candidate:skill-a 90 user-101 85 user-102 80 user-103
# 第二个集合与第一个集合共享 user-101、user-103
redis-cli ZADD candidate:skill-b 88 user-101 82 user-103 75 user-104

这里的分数不会改变“某个成员是否同时存在”的交集判断。对 ZINTERCARD 来说，关键输入是参与计算的键，而不是把分数当成过滤条件。

用 ZINTERCARD 得到交集数量

命令的核心格式是 ZINTERCARD numkeys key [key ...]。numkeys 表示后面有多少个集合键，必须与实际传入的键数量一致：

# 2 表示后面紧跟两个参与计算的有序集合键
redis-cli ZINTERCARD 2 candidate:skill-a candidate:skill-b

2

返回值为整数 2，表示两个键共有两个成员。它不会返回 user-101 和 user-103 的名字，也不会创建交集结果键；如果后续还要读取成员本身，就应该选择能返回成员的其他命令或单独设计数据读取步骤。

比较三个集合时，先把 numkeys 改成 3，再连续传入三个键：

# 三个集合必须和 numkeys=3 一一对应，避免把业务键错当成选项
redis-cli ZINTERCARD 3 candidate:skill-a candidate:skill-b candidate:region-east

我在封装客户端方法时，会把键列表作为一个整体参数传递，先计算列表长度，再把长度和值依次交给 Redis 客户端。这样比手写固定的 2、3 更不容易在集合数量变化后漏改参数。

把返回整数映射为匹配判断

假设业务规则是“至少有 2 个共同成员才认为匹配”，准确计数的判断就是把返回值和门槛比较：

# 先取精确交集数量，再由调用方与业务门槛比较
matched_count=$(redis-cli --raw ZINTERCARD 2 candidate:skill-a candidate:skill-b)
# shell 算术判断只负责示例中的门槛映射，不修改 Redis 中的数据
if [ "$matched_count" -ge 2 ]; then
  echo "matched"
else
  echo "not matched"
fi

这段判断的重点是“数量”和“是否达标”分开：Redis 负责返回基数，应用负责决定 2、3 还是其他门槛。这样后续调整业务规则时，不需要修改集合内容或增加临时结果键。

如果业务只需要知道“有没有达到门槛”，可以使用 LIMIT 让 Redis 在交集数量达到上限后停止继续计算：

# 达到 2 就足以判定匹配，LIMIT 用于提前停止，不代表真实总数
redis-cli ZINTERCARD 2 candidate:skill-a candidate:skill-b LIMIT 2

当真实交集大于或等于 2 时，这种写法可能只返回 2。因此它适合“是否至少达到 2”的门槛判断，不适合展示精确总数、排序统计或报表汇总。要知道完整数量，就不要用一个会截断计算结果的上限代替精确查询。

不存在的键会怎样

参与交集计算的键如果不存在，Redis 会把它看作空集合。只要多个输入中有一个是空集合，交集数量就会是 0。这对“多条件同时满足”的筛选很自然，但也容易掩盖键名拼写错误：

# candidate:region-east 不存在时，会按空集合参与交集
redis-cli ZINTERCARD 3 candidate:skill-a candidate:skill-b candidate:region-east

所以在排查“为什么突然全部不匹配”时，我会先确认集合键是否按预期写入，再解释返回的 0。不要因为命令没有报错，就把结果当成“业务确实没有共同成员”。

多键查询的工程边界

ZINTERCARD 是只读查询，不会改动输入集合；但它仍然是一个带多个键的命令。使用 Redis Cluster 时，多键命令还要符合集群的键路由约束，不能只在单机环境验证成功后就默认所有键组合都能直接执行。

另外，ZINTERCARD 返回的是数量，不是成员和分数。如果调用方下一步需要具体成员、需要把结果保存下来，或者需要对交集结果排序展示，就不能把它当作完整的交集替代品。本文只把它定位为“基数查询和门槛判断”工具。

几个容易混淆的判断

相关问题

ZINTERCARD 会比较有序集合的分数吗？

它返回的是交集成员数量，本文的判断只关心成员是否同时存在，不把分数当作范围过滤条件。

为什么 LIMIT 返回值不能当成精确数量？

LIMIT 的用途是达到门槛后提前停止计算。当真实交集更大时，返回值可能停在门槛上，因此只能用于“至少达到多少”的判断。

一个键为空时还需要自己先判断吗？

不需要为了命令正确性额外先查空键；Redis 会按空集合参与计算。但业务排障时仍要区分“确实没有交集”和“键根本没有写入”。

最后可以把用法压缩成一句话：需要准确统计时直接执行 ZINTERCARD numkeys key...，只判断是否达到共同成员门槛时再使用 LIMIT，并始终把“不存在键”的情况纳入排障判断。