Redis用Set实现共同关注，核心是将用户关注列表存为Set并用SINTER求交集，具有高效、去重、低延迟优势；需同步更新Redis与数据库，注意内存管理与元信息扩展。
用 Redis 的 Set 实现共同关注，核心就是把每个用户的关注列表存成一个 Set，再用交集命令（SINTER）直接算出两人共同关注的人。它快、准、天然去重，比数据库 JOIN 查询更适合高并发场景。
关注数据怎么存？
每个用户对应一个 Set，key 命名为 following:{userId}，value 是他关注的用户 ID 列表（字符串形式）。
- 用户 1001 关注了 2001、2002、2003 → 执行
SADD following:1001 2001 2002 2003 - 用户 1002 关注了 2002、2003、2004 → 执行
SADD following:1002 2002 2003 2004 - 后续增删用
SADD/SREM，查全部用SMEMBERS following:1001
怎么查共同关注？
直接调用 SINTER 命令，传入两个用户的关注 Set key：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
SINTER following:1001 following:1002→ 返回2002和2003 - 时间复杂度是 O(N×M)，N 是较小集合的大小，M 是集合个数（这里为 2），实际响应在毫秒级
- 结果自动去重、无序，符合“共同关注”语义
怎么支持分页和数量统计？
单纯 SINTER 返回全部结果可能太大，生产环境建议分层处理：
- 查总数：先用
SCARD获取各自关注数，再用SINTERSTORE temp_key following:1001 following:1002把交集暂存，最后SCARD temp_key得总数，再DEL temp_key清理 - 查分页列表：用
SINTERSTORE存交集后，配合SRANDMEMBER temp_key count或搭配 Lua 脚本做随机/有序抽样（若需排序，可额外用 ZSET 同步维护时间戳） - 避免大集合阻塞：对超大关注量用户（如百万粉博主），可预计算热门交集缓存，或用布隆过滤器前置过滤
要注意什么？
Set 虽好，但得配合业务逻辑用稳：
- 关注/取关操作必须同步更新 Redis Set 和数据库（如 MySQL 的 tb_follow 表），保证最终一致性
- Set 不保存关注时间等元信息；如需按时间排序共同关注，得额外用 ZSET 存储，并在写时双写
- 内存占用随用户关注数线性增长，建议设置合理的过期策略（如长期不活跃用户 Set 可 TTL 自动清理）
- 注意 key 命名规范，比如加业务前缀
social:following:1001，方便集群隔离和监控
