Redis 怎么用集合交集筛选同时满足多个标签的用户

做“同时满足多个标签”的筛选时，别先把每个标签的用户 ID 拉到应用层再用代码求交集。Redis 的 Set 原生支持多键交集，直接用 SINTER 就能把“标签 A 且标签 B 且标签 C”变成一次 Redis 查询。

把用户 ID 按标签反向写入 Set，例如 user:tag:golang 和 user:tag:redis，再执行 SINTER user:tag:golang user:tag:redis。返回的是同时属于这些 Set 的用户 ID；需要复用时改用 SINTERSTORE 保存结果。

Redis 集合交集到底返回什么

Redis 的 Set 适合表达“某个用户属于某个标签”。如果一个用户同时有 Go 和 Redis 两个标签，他的 ID 会同时存在于两个 Set。此时交集就是 AND 条件；如果业务是“有任意一个标签”，才应该考虑 SUNION。

官方命令文档把 SINTER 描述为返回多个 Set 的交集，语法是 SINTER key [key ...]。所以它解决的是“筛 ID”，不是“查完整用户资料”；拿到 ID 后，再由应用层访问用户表或缓存详情。

先用 SADD 建立按标签反向索引

索引的关键是“标签做 key、用户 ID 做 member”。下面的示例用三个用户维护两个标签，命令中的注释只说明数据意图，不代表真实运行结果。

# 写入标签反向索引：Set 的成员只保存稳定用户 ID
redis-cli SADD user:tag:golang u1001 u1002 u1003
redis-cli SADD user:tag:redis u1002 u1003

# 取同时拥有两个标签的用户 ID
redis-cli SINTER user:tag:golang user:tag:redis

# 业务层拿到 ID 后，再批量读取用户详情，不把详情写进 Set

在这个模型里，u1002 和 u1003 才会进入交集。标签移除时用 SREM 删除成员，用户删除或注销时也要同步清理相关标签集合；否则交集结果会出现已经失效的 ID。

标签 key 建议包含明确的命名空间，例如 user:tag:golang。若标签来自用户输入，应先做长度、字符集和业务白名单限制，避免把不可控字符串直接拼进 key。

读取结果还是保存结果：SINTER 与 SINTERSTORE 怎么选

只需要本次请求的候选用户时，用 SINTER。它返回成员列表，原始标签集合不会改变。若同一交集会被多个后续请求复用，可以使用 SINTERSTORE 把结果写入目标 key：

# 将交集写入独立结果 key，便于后续分页或复用
redis-cli SINTERSTORE segment:golang-redis user:tag:golang user:tag:redis

# 检查结果数量；结果 key 需要单独设计生命周期
redis-cli SCARD segment:golang-redis
redis-cli EXPIRE segment:golang-redis 300

SINTERSTORE 会覆盖目标 key 的旧内容；如果交集为空，目标 key 会变成空结果。这个行为适合短时计算结果，不适合把它当成永远正确的用户分群。标签发生变化时，缓存的交集仍可能短暂过期，业务要接受这种延迟，或在写标签后主动删除结果 key。

如果只需要人数而不需要 ID 列表，可以优先使用计数型命令，减少网络返回数据。无论选择哪一种命令，都要给结果 key 与原始标签 key 使用清晰的过期和失效策略。

成员量变大时先缩小最小集合

Redis 官方给出的 SINTER 最坏复杂度是 O(N*M)，其中 N 是最小集合的基数，M 是集合数量。工程上可以把它理解为：输入集合越多、最小集合越大，一次交集要检查的候选就越多。因此，给标签建立索引时应避免所有用户都塞进一个“超级标签”，并在高频查询前观察各集合基数。

多标签筛选还要注意部署形态。Redis Cluster 的多键命令要求涉及的 key 位于同一 hash slot，可以用 hash tag 让相关 key 共享槽位，例如：

# 用相同的 {audience} hash tag，让多键 SINTER 具备同槽命名基础
redis-cli SADD '{audience}:tag:golang' u1001 u1002
redis-cli SADD '{audience}:tag:redis' u1002
redis-cli SINTER '{audience}:tag:golang' '{audience}:tag:redis'

这里的花括号只是 Redis Cluster 的 hash tag 约定，不是为了改变集合内容。上线前可用 CLUSTER KEYSLOT 检查相关 key 是否得到相同槽位；非集群 Redis 不需要这一步。

常见问题

SINTER 的返回结果有固定顺序吗？

不要把 Set 交集当作排序结果使用。需要分页、排序或按活跃度展示时，先得到 ID，再交给有序集合、数据库查询或应用层排序，并明确稳定的排序字段。

能不能直接用 SINTER 查出用户昵称和头像？

不能。Set 成员只是用户 ID 或其他字符串成员。交集完成后，使用这些 ID 批量读取详情，避免把经常变化的资料复制到多个标签集合。

标签变化后为什么结果 key 还保留旧用户？

如果使用了 SINTERSTORE，结果是一次计算的快照，不会随源 Set 自动更新。写入或删除标签后，应删除相关结果 key，或者设置较短 TTL 并接受缓存窗口。

实际落地时可以按“标签反向索引、交集筛 ID、详情再查询、结果按需缓存”拆开设计。这样既保留 Redis Set 的简单语义，也能把集合规模、集群槽位和缓存一致性分别控制住。