Java中用Redis Set处理社交关注与共同好友，核心是SADD存关注、SINTER算交集；需规范key命名（如follow:{uid}）、注意大Set性能瓶颈并合理缓存结果。
在 Java 中用 Redis 的 Set 类型处理社交关注和共同好友，核心是利用 Set 的无序唯一性与集合运算能力：SADD 存关注关系，SINTER 算交集得共同好友，高效且天然去重。
用 Jedis 或 Lettuce 执行 SADD 维护用户关注列表
每个用户的关注列表用一个 key 表示（如 follow:1001），每次关注就 SADD 一个目标用户 ID。Set 天然去重，重复关注不会冗余存储。
- 使用 Jedis 示例：
jedis.sadd("follow:1001", "2001", "2002", "2003");
表示用户 1001 关注了 2001、2002、2003 - 取消关注用 SREM：
jedis.srem("follow:1001", "2002"); - 推荐把 key 命名规范化，比如 follow:{uid} 和 follower:{uid} 分开存“我关注的人”和“关注我的人”，方便双向查询
用 SINTER 快速提取两个用户的共同好友
共同好友 = 用户 A 的关注列表 ∩ 用户 B 的关注列表。只要两者都用 Set 存关注关系，一条 SINTER 就能返回交集结果。
- 例如查用户 1001 和 1002 的共同关注：
Set<string> common = jedis.sinter("follow:1001", "follow:1002");</string> - 注意：SINTER 要求所有 key 都存在；若某个用户还没关注任何人（key 不存在），结果为空集。可先用 EXISTS 或直接接受空结果，业务层按需处理
- 如果要查“我和某人的共同好友”，只需把当前用户 key 和对方 follow key 传入 SINTER，无需遍历或数据库 join
扩展场景：多用户共同关注、带权重的共同好友
原生 SINTER 只支持等权交集，但可通过组合命令支持更复杂逻辑。
立即学习“Java免费学习笔记（深入）”；
- 三人及以上共同关注：SINTER 支持多个 key，
jedis.sinter("follow:1001", "follow:1002", "follow:1003") - 想优先展示“被更多人共同关注”的好友？可先用 SUNION 把多个关注列表合并，再用 SINTERCARD（Redis 7.0+）或配合 SCARD + SORT 实现频次统计
- 临时计算后结果可缓存（如 key=common:1001:1002，TTL 设为 5–30 分钟），避免高频重复计算
注意事项与性能提醒
Set 操作时间复杂度低（SADD O(1)，SINTER O(N*M)，N、M 是各 Set 元素数），但在用户关注量极大（如百万级）时需谨慎。
- 单个 Set 不宜过大：超过 10 万元素时，SINTER 延迟可能上升；可考虑分片（如按关注时间分月 key）或改用 Sorted Set 加 score 做热度排序
- 避免在大流量接口中直接调用多 key SINTER；高并发下建议加本地缓存（Caffeine）或预热常用组合结果
- 务必设置合理的超时和连接池参数（尤其 Lettuce 的线程模型），防止 Redis 连接阻塞影响整个服务
