在Redis的五大数据类型中，集合（Set）是最容易被低估的一个，它天生支持去重，更重要的是提供了丰富的集合运算命令。其中SINTER用于计算多个集合的交集，是标签匹配、共同好友、商品筛选等场景的核心武器。本文将围绕SINTER的语法、底层原理、实战用法和性能优化展开，带你彻底掌握这个命令。
SINTER的基本语法与使用方式
SINTER的语法非常简单：SINTER key [key ...]。传入一个或多个集合键，返回所有集合中共同存在的成员。当只传入一个key时，它等价于返回该集合的全部成员；如果任意一个key不存在，Redis会把它当作空集合处理，结果自然是空数组。如果传入的某个key实际存储的不是集合类型，会直接返回 WRONGTYPE 错误。
SADD tags:article1 redis database nosql SADD tags:article2 redis performance cache SADD tags:article3 redis database SINTER tags:article1 tags:article2 # 返回结果：redis（两个集合中只有 redis 是共同的） SINTER tags:article1 tags:article3 # 返回结果：database redis
与SINTER配套的还有一个常用变体SINTERSTORE，它的区别在于不直接返回结果，而是把交集写入到指定的目标key中。如果目标key已存在，会被覆盖。这在需要持久化交集结果或后续继续运算的场景下非常实用，例如先算出两个用户标签的交集，再用SDIFF做二次加工。
SINTERSTORE result tags:article1 tags:article2 # 返回交集成员数量，例如：1 SMEMBERS result # 返回结果：redis
底层原理：Redis是如何高效计算交集的
Redis计算交集的思路并不复杂：先遍历最小的那个集合，然后逐个检查每个成员是否存在于其他集合中，只有全部命中的成员才会被加入结果集。这个策略保证了比较次数最少，因为小集合的候选成员最少，能尽早排除不可能出现在交集中的元素。
具体到编码层面，当集合以整数集合（intset）编码存储时，成员查找基于有序数组，可以利用二分查找快速定位，时间复杂度为O(log N)。当集合转换为哈希表（hashtable）编码后，成员查找的复杂度接近O(1)，这也是Redis在数据量增大后自动完成编码转换的原因。两种编码的自动切换对上层完全透明，开发者无需关心。
需要特别注意的一点是，SINTER是一个同步命令，计算过程发生在Redis主线程中。如果参与运算的集合非常大，例如两个各有百万成员的集合求交集，计算过程可能耗时数百毫秒甚至更长，期间整个Redis实例的其他请求都会被阻塞。单线程架构决定了这一点，这也是使用SINTER时最大的风险来源。可以粗略估算：N个小集合，总复杂度约为遍历最小集合的每个成员乘以剩余集合的查找成本，哈希表编码下整体接近O(M)，M为最小集合的成员数。
典型应用场景与代码示例
第一个经典场景是共同好友。假设用集合存储每个用户的好友ID，两个用户的好友集合做一次SINTER就能立刻得到共同好友列表，比在应用层把数据拉到内存中自己比对高效得多。第二个场景是商品筛选，例如电商平台将品牌、价格区间、品类分别维护为商品ID集合，用户勾选多个筛选条件时对相应集合求交集即可得到候选商品。
import redis
r = redis.Redis(host='127.0.0.1', port=6379, decode_responses=True)
# 构造两个用户的好友集合
r.sadd('friends:user:1001', 1002, 1003, 1004, 1005)
r.sadd('friends:user:1002', 1003, 1004, 1006)
# 计算共同好友
common = r.sinter('friends:user:1001', 'friends:user:1002')
print(common) # 输出：{'1003', '1004'}
# 将交集结果存储，方便后续分页或二次计算
count = r.sinterstore('common:1001:1002', 'friends:user:1001', 'friends:user:1002')
print('共同好友数量:', count)Java开发者使用Jedis时写法类似，核心API为jedis.sinter(keys)和jedis.sinterstore(dst, keys)。在标签推荐场景中，常见做法是把用户感兴趣的标签集合与每篇文章的标签集合求交集，交集越大说明匹配度越高，可以按交集大小对候选内容排序，实现简单有效的个性化推荐。
性能优化与注意事项
面对大集合，第一步是控制参与运算的集合规模。业务设计上应尽量避免让单个集合无限制膨胀，比如按时间分片存储，tags:20240601、tags:20240602，查询时只对必要的分片求交集。时间复杂度取决于最小集合，因此把高频大集合拆小往往比优化其他环节收益更大。
第二步是考虑预计算。如果某个交集会被反复查询，可以在数据写入阶段就通过SINTERSTORE把结果缓存下来，配合合理的过期时间，把实时计算变成一次性的写入成本。还可以借助Redis Cluster或主从读写分离，把这类重计算请求路由到从节点执行，避免影响主节点处理写入请求。对于特别复杂的运算，也可以把数据同步到应用内存中用高级语言计算，Redis只承担存储职责。
最后要留意版本演进带来的改进。Redis 6.2引入了SINTERCARD命令，可以指定最多参与运算的key数量并限制结果基数，在只需要判断交集规模时能减少不必要的数据传输。线上使用时建议配合慢查询日志（slowlog）监控SINTER的执行耗时，一旦发现耗时异常，及时调整集合结构或改为异步计算方案，才能保证服务的整体稳定性。