Redis SINTERCARD 为什么不能统计重复出现次数

Redis SINTERCARD 不能统计重复出现次数，核心原因是这个命令本身是针对 Set 集合类型设计的，而 Set 类型的特性就是成员全局唯一，同个元素重复写入也只会保留一份，根本不存在重复计数的数据源，自然没法统计元素重复出现的次数。

如果业务侧有统计重复元素交集次数的需求，可以改用支持重复值的有序集合或者哈希表结构来实现，不要直接基于 SINTERCARD 做二次改造。

Redis 的 SINTERCARD 统计的是多个集合交集里有多少个不同成员，不是某个成员在原始数据中被写入了几次。这个结果由两层语义决定：Redis 的 SET 本身不保存重复成员，而 SINTERCARD 只返回交集的基数。

官方地址：https://redis.io/

SINTERCARD 适合回答“同时属于这些集合的成员有多少个”。如果要回答“每个成员出现在多少个集合中”或“同一成员累计出现了几次”，必须在写入时保留计数，不能从已经去重的 SET 中反推。

先区分两个容易混淆的统计问题

假设有两个集合：一个表示“本周购买过商品”，另一个表示“本月领取过优惠券”。使用 SINTERCARD 2 buyers coupons，问题是找出同时满足两种条件的用户数量。这里每个用户在每个集合中只有一个成员身份，交集结果自然也是去重后的成员数量。

“重复出现次数”则可能指两种不同需求：

• 同一个成员在同一个集合里重复写入了几次；
• 同一个成员出现在多少个不同集合里。

第一种次数在 SET 写入完成后就丢失了；第二种需要统计并集中的成员分值，不能用交集基数代替。

SINTERCARD 为什么天然不会返回重复次数

SADD 对同一个集合里的既有成员不会再创建副本。下面的示例中，第二次写入 u100 不会让集合多出一个可计数的元素：

# 第一次加入两个用户，返回实际新增的成员数
redis-cli SADD buyers u100 u200

# u100 已经存在，只会新增 u300，不会保存第二份 u100
redis-cli SADD buyers u100 u300

# 查看集合基数，结果只按不同成员计数
redis-cli SCARD buyers

# 统计 buyers 与 coupons 交集里的不同成员数
redis-cli SINTERCARD 2 buyers coupons

因此，即使业务日志里曾经出现过多条 u100，只要写入模型是 SET，Redis 也只知道“u100 是否存在”。SINTERCARD 接着对这些成员做交集计算，返回值不会包含被丢弃的重复写入记录。

用 SINTER、SINTERCARD 还是 SINTERSTORE

三个命令都围绕“交集成员”工作，但适合的输出不同。可以按结果需求选择：

如果只是做分页前的数量估算，SINTERCARD 比先取回全部成员再在应用层计数更直接。它的返回值仍然只是一个整数，不能拿来推断某个成员在各集合中的出现次数。

要统计跨集合出现次数，改用计数模型

当每个输入集合代表一次来源、一个标签或一个时间窗口，并且你想知道成员出现在多少个集合中，可以让每个集合对应一个有序集合，成员分值统一写成 1。再用 ZUNIONSTORE 的 SUM 聚合相同成员的分值：

# 每个来源集合里的成员分值都设为 1，表示出现于该来源
redis-cli ZADD source:week1 1 u100 1 u200
redis-cli ZADD source:week2 1 u100 1 u300
redis-cli ZADD source:week3 1 u100 1 u400

# SUM 会把同一成员在不同来源中的 1 相加
redis-cli ZUNIONSTORE member:source-count 3 source:week1 source:week2 source:week3 AGGREGATE SUM

# 查看成员与出现来源数；u100 的分值应为 3
redis-cli ZRANGE member:source-count 0 -1 WITHSCORES

# 只保留至少出现在两个来源中的成员，避免把单次出现混入重复项
redis-cli ZRANGESTORE member:repeated member:source-count 2 +inf BYSCORE

这个方案统计的是“出现在多少个集合”，不是同一个集合内的重复写入次数。如果业务需要统计同一来源中的次数，应在写入时递增分值，例如用 ZINCRBY 或哈希计数；不要先用 SET 去重，再试图恢复已经消失的次数。

LIMIT 只限制交集计数，不会打开重复记录

SINTERCARD 还支持可选的 LIMIT：

# 找到 10 个交集成员后即可停止继续计算
# LIMIT 不改变 SET 的去重语义，也不返回是哪 10 个成员
redis-cli SINTERCARD 2 buyers coupons LIMIT 10

当 LIMIT 为正数时，它可以让“只关心是否达到某个门槛”的场景尽早结束；省略它或使用 LIMIT 0 表示不设置这个上限。它限制的是交集计数过程，并不是把重复出现的成员重新展开。

还要注意输入键的数量和位置：第一个参数是参与运算的键数量，后面紧跟对应数量的集合键。命令的复杂度与最小集合的成员数和输入集合数量有关，集合很大时应先确认是否真的只需要一个基数。

选择命令前的速查结论

1. 问“共同成员有多少个”：用 SINTERCARD。
2. 问“共同成员是谁”：用 SINTER。
3. 问“交集是否要复用”：用 SINTERSTORE。
4. 问“成员出现在多少个集合”：用统一分值的 ZSET 加 ZUNIONSTORE ... AGGREGATE SUM。
5. 问“同一个来源累计写入几次”：从写入阶段维护计数，不能依赖 SET 事后恢复。

所以，Redis SINTERCARD 不能统计重复出现次数并不是参数用错，而是数据结构和命令职责决定的：SET 保证成员唯一，SINTERCARD 只计算交集的基数。先明确“交集数量”还是“出现次数”，再选择集合或计数模型，结果才不会被误读。

相关问题

• SINTERCARD 与 SINTER 的主要差异是返回整数还是成员列表。
• 如果只需要判断交集是否达到阈值，可以配合正数 LIMIT 减少无用计算。
• 如果计数按时间窗口变化，应为每个窗口独立维护计数键，过期时一起清理。