Redis ZINTERCARD 怎么做集合交集预判：基数统计、LIMIT 与误用边界

活动页上线前，接口通常要同时判断“参加过活动”“满足城市条件”“仍在有效会员期”这几组人群。若只是想知道符合条件的人数，直接用 ZINTER 生成完整结果集，会把不需要的数据搬进 Redis 结果键。Redis 7.0 提供的 ZINTERCARD 更适合做这个预判：它只返回多个 Sorted Set 的交集基数，必要时还可以在达到阈值后提前停止。

先把“有没有交集”和“交集有多少”分开

假设资格集合用 Sorted Set 保存，member 是用户 ID，score 是加入时间：

redis-cli ZADD campaign:joined 1719800000 u:1001 1719800001 u:1002 1719800002 u:1003
redis-cli ZADD campaign:city:sh 1 u:1002 2 u:1003 3 u:1008
redis-cli ZADD member:active 1 u:1003 2 u:1008

现在要判断上海有效会员里是否有人参加了活动。只判断存在性时，可以这样写：

redis-cli ZINTERCARD 3 campaign:joined campaign:city:sh member:active LIMIT 1

返回 1，表示至少找到一个交集成员。这里的 1 是满足上限后的结果，不应该被业务解释成“完整交集只有 1 人”。如果报表要展示准确人数，就去掉 LIMIT，让 Redis 完整计算基数。

三个候选命令，选择点不在名字而在返回结果

线上最容易出现的误用，是把“计算交集”“统计交集”“判断是否存在”混成一个动作。它们的网络返回和 Redis 端工作量并不一样。

ZINTER 的结果还需要写入目标 key，或者通过客户端拿回成员列表；当交集很大而调用方只想知道数量时，这部分内存和网络开销没有必要。反过来，ZINTERCARD 不返回成员，不能拿它替代后续的名单查询。

LIMIT 的真实含义：达到阈值就停，不是分页

LIMIT 是阈值截断，不是返回前 N 个成员，也不是把交集结果分页。用刚才的三组集合演示：

redis-cli ZINTERCARD 3 campaign:joined campaign:city:sh member:active
redis-cli ZINTERCARD 3 campaign:joined campaign:city:sh member:active LIMIT 1
redis-cli ZINTERCARD 3 campaign:joined campaign:city:sh member:active LIMIT 10

第一条返回完整基数；第二条只保证结果不会超过 1，适合“有没有”的判断；第三条在完整交集不足 10 人时返回真实数量，达到 10 时即可返回 10。这个语义很适合接口里的布尔条件：

交集人数 = ZINTERCARD(..., LIMIT 1)
交集人数 > 0  -> 允许继续
交集人数 = 0  -> 直接结束

不要拿 LIMIT 20 的返回值画精确报表。返回 20 只说明“至少 20 个”，并没有说明是 20、200 还是 20000 个。

把四个边界放进验收脚本

命令能返回数字，不代表业务口径已经正确。至少把下面四个边界跑一遍，尤其是 key 不存在和集合成员为空的情况。

# 完整交集：应返回 1（只有 u:1003 同时满足三项）
redis-cli ZINTERCARD 3 campaign:joined campaign:city:sh member:active

# 空 key：应返回 0，不会因为 key 不存在而报“没有这个集合”
redis-cli ZINTERCARD 3 campaign:joined campaign:city:sh member:missing

# 阈值判断：应只返回 1，不把它当成完整人数
redis-cli ZINTERCARD 3 campaign:joined campaign:city:sh member:active LIMIT 1

# 输入 key 数量错误：numkeys 必须与后面的 key 个数一致
redis-cli ZINTERCARD 3 campaign:joined campaign:city:sh

最后一条故意留下错误，用来确认客户端能把 Redis 的参数错误记录下来，而不是把异常当作 0 人。生产代码中还应把“完整计数”和“阈值计数”区分成两个方法名，避免调用方看见一个整数就误读。

什么时候不该用 ZINTERCARD

这个命令有三个明确的停用信号。

• 需要成员列表。交集基数无法告诉你是哪几个用户，后续仍要重新查询或改用 ZINTER。
• 集合很大且调用频率高。官方给出的最坏复杂度是 O(N*K)，N 是最小输入 Sorted Set 的成员数，K 是输入 key 数量。调用前应看集合规模，必要时把更小的集合放在候选输入中。
• 集群 key 不在同一槽。多 key 命令需要按 Redis 集群规则规划 key 名，使用 hash tag 让相关集合落在同一槽，否则客户端可能在发送前就拒绝请求。

另外，Sorted Set 的 score 只参与集合结构本身的存储；ZINTERCARD 返回的是 member 的交集数量，不是 score 的和、最大值或时间范围统计。要按分数筛选，应先把时间窗口拆进 key，或选择能够表达分数条件的查询方案。

一张决策表收口：先问结果要什么

常见问题

ZINTERCARD 支持普通 Set 吗？

不支持。它面向 Sorted Set 交集基数；如果数据是普通 Set，应使用对应的集合命令，或者先确认数据结构是否真的需要 score。

LIMIT 0 是返回 0 吗？

不是。官方语义里 LIMIT 0 表示不限制，返回完整交集基数；只有正数才会在达到阈值后提前停止。

不存在的 key 会让 ZINTERCARD 报错吗？

不会。不存在的 key 按空集合处理，因此交集结果为 0。参数数量、数据类型或集群槽位问题仍可能报错，需要单独记录。

能用 ZINTERCARD 做“前 10 个用户”吗？

不能。它只返回数量，而且 LIMIT 是停止阈值，不是按 score 排序后取前 10 个成员。需要名单时应改用能返回成员的查询命令。

把 ZINTERCARD 放在“结果选择”之前，通常就能避免无意义的交集结果写入。存在性判断用 LIMIT 1，精确统计不用 LIMIT，需要名单再回到 ZINTER；剩下的重点是集合规模、key 设计和集群槽位是否支持这个调用。