redis点赞与共同好友功能基于set实现：点赞用sismember/sadd/srem操作blog:liked:{id}集合；共同好友通过sinter计算follow:{uid}集合交集，支持差集推荐、多用户交集及频次统计，需注意大集合阻塞与原子性优化。
Redis 实现点赞与共同好友，核心是用对数据结构——Set 天然支持去重、成员判断和集合运算，不依赖数据库 join，响应快、代码简洁。
点赞功能：用 Set 判断是否已点
每个被点赞对象（比如一篇博客、一条评论）对应一个 Set，key 形如 blog:liked:123，value 存用户 ID。
- 用户点击点赞时，先用
SISMEMBER blog:liked:123 1001查是否已存在；不存在则执行SADD并更新数据库点赞数 - 取消点赞直接
SREM移除，再减数据库计数 - 前端展示“已点赞”状态，只需查一次
SISMEMBER，毫秒级返回
共同好友/共同关注：用 SINTER 算交集
把每个用户的好友或关注列表单独存为 Set，key 命名规范很重要，例如：
-
follow:1001→ 用户 1001 关注的人（即“我关注谁”） -
follower:1001→ 关注用户 1001 的人（即“谁关注我”） - 查用户 A 和 B 的共同关注：直接
SINTER follow:1001 follow:1002，结果自动去重、无序 - 若要查“我和某博主的共同关注”，传入
follow:{当前用户ID}和follow:{博主ID}即可
扩展场景：差集推荐、多用户交集
基础集合操作就能支撑更多社交逻辑：
- 给用户 A 推荐“B 有而 A 没关注的人”：用
SDIFF follow:1002 follow:1001 - 三人及以上共同关注：
SINTER follow:1001 follow:1002 follow:1003，原生命令支持任意数量 key - 想按“被共同关注频次”排序？可先
SUNION合并多个关注列表，再结合SCARD或 Redis 7.0+ 的SINTERCARD统计出现次数
注意事项与优化点
实际落地时几个关键细节不能忽略：
- key 不存在时
SINTER返回空集合，无需提前EXISTS判断，业务层直接处理空结果即可 - 超大关注列表（如百万级）做
SINTER可能阻塞，建议对高频请求缓存结果，并设置合理过期时间 - 关注/取关操作必须保证原子性，可用 Lua 脚本封装
SADD + SCARD或SREM + SCARD逻辑 - Spring Boot 中推荐用
StringRedisTemplate.opsForSet()，比原生 Jedis 更易集成事务与序列化
