系统设计 018共同好友与六度人脉Bilibili 同步视频 一、共同好友功能从业务逻辑到缓存性能优化✨ 业务价值定位 核心实现原理 业务流量特征⚡ 性能痛点与缓存优化方案 核心伪代码实现 二、六度人脉关系职场社交平台架构设计实战✨ 六度人脉理论基础 人脉度数定义规则 业务落地场景 核心需求约束❌ 传统 BFS 算法的线上致命缺陷⚖️ 双向 BFS 的能力局限 三、架构终极解法离线预计算 在线轻量查询 设计核心思想 人脉度数判定规则 性能结果复盘 四、架构设计的关键取舍思维 写在最后在互联网社交产品的底层架构中好友关联匹配与人脉度数推演是两大核心基础能力。无论是日常社交 APP 的共同好友推荐还是职场社交平台的六度人脉展示背后都藏着精妙的逻辑设计、算法取舍与性能优化思路。今天我们从业务场景、底层实现、算法选型、性能调优、架构取舍多个维度深度拆解这两大经典社交技术方案。Bilibili 同步视频系统设计 018共同好友与六度人脉 一、共同好友功能从业务逻辑到缓存性能优化✨ 业务价值定位共同好友是社交场景里天然的信任纽带。当我们与陌生用户尚未建立好友关系时共同好友数据可以作为重要参考依据辅助我们判断对方是否为潜在熟人进而决策是否发起好友申请极大提升社交匹配的精准度。 核心实现原理该功能本质是集合交集运算对外提供统一接口入参传入两个用户唯一标识userID_A、userID_B分别查询用户 A 的好友列表、用户 B 的好友列表对两份好友 ID 集合求取交集最终返回交集内的所有用户 ID即为二人共同好友。 业务流量特征社交场景下共同好友功能具备典型的读多写少特性读操作用户浏览资料、推荐好友时频繁查询共同好友关系写操作新增好友、删除好友的变更频次远低于查询频次。⚡ 性能痛点与缓存优化方案若直接基于数据库做 Key-Value 查询高并发场景下会频繁穿透数据库造成DB 压力飙升、接口响应延迟。最优解法是引入Memcached 做热点数据缓存将每个用户的好友列表提前缓存至 Memcached 中原本两次数据库 KV 查询直接替换为两次缓存 KV 查询避开磁盘 IO 瓶颈接口响应速度实现量级提升。 核心伪代码实现# 获取两个用户的共同好友defget_common_friends(user_id_a:str,user_id_b:str)-list:# 从Memcached缓存读取好友列表替代数据库查询friend_list_amemcached.get(ffriend:{user_id_a})friend_list_bmemcached.get(ffriend:{user_id_b})# 集合求交集得到共同好友set_aset(friend_list_a)set_bset(friend_list_b)common_friendslist(set_aset_b)returncommon_friends 二、六度人脉关系职场社交平台架构设计实战✨ 六度人脉理论基础六度人脉理论是社交领域经典猜想世界上任意两个陌生人最多只需要经过六层人脉中间人就能建立连接。依托该理论职场社交平台衍生出人脉度数展示能力成为产品核心特色。 人脉度数定义规则一度人脉双方为双向直接好友距离为 1二度人脉无直接好友关系但拥有至少一位共同好友距离为 2三度人脉通过两层中间人才能建立关联距离为 3三度 人脉超过三度的人脉关系统一归类展示为「三度 」。 业务落地场景搜索场景输入人名搜索用户后搜索结果列表会标注与自身的人脉度数主页场景进入他人个人主页时展示访客列表并标注每位访客的人脉关联度数。 核心需求约束无需全量用户人脉排序仅需对搜索结果前 8~10 个指定用户计算人脉度数平台体量亿级用户规模单用户平均好友数约 1000 人性能红线数据库请求必须控制在常数级最优 10 次左右严禁超过 20 次。❌ 传统 BFS 算法的线上致命缺陷从算法层面看好友关系可抽象为无向无权图人脉度数就是两点间最短路径很多人第一时间会想到用BFS 宽度优先搜索实现。但落地到线上生产环境存在无法规避的性能灾难从用户 A 出发做一层 BFS 拓展1 次 DB 查询获取约 1000 个一度好友二层 BFS 拓展需要逐个查询 1000 个一度好友的好友列表DB 请求直接飙升至千级在线服务无法承受千级数据库请求接口响应超时、服务卡顿成为必然。算法场景中我们默认循环、遍历是 O (1) 轻量操作但数据库查询是重型 IO 操作连 O (n) 级请求都无法容忍必须严格控制在 O (1) 常数级。⚖️ 双向 BFS 的能力局限有人提出用双向宽度优先搜索优化同时从用户 A、目标用户 B 两端拉取好友列表内存中求交集。该方案仅能精准判断二度人脉面对三度及以上的人脉关系完全无能为力存在天然的能力边界。 三、架构终极解法离线预计算 在线轻量查询 设计核心思想放弃在线实时图遍历采用空间换时间的架构思路把复杂的计算压力转移到离线环节在线只做轻量集合比对。离线批量预计算后台利用集群算力异步全量计算平台所有用户的一度好友、二度好友关系将结果持久化存储至 MySQL/NoSQL通过 Key 前缀区分度数类型例如friend_1:{userID}代表一度人脉、friend_2:{userID}代表二度人脉。亿级用户体量下仅需 1~3 天即可完成全量数据刷新不影响线上业务。在线极简查询逻辑仅需 2 次 DB 查询获取自身 A 的一度、二度人脉集合批量 810 次 DB 查询获取目标用户列表 B1B10 的一度人脉集合内存做集合交集比对无需额外数据库请求。 人脉度数判定规则1. A一度人脉 ∩ B一度人脉 有交集 → 一度人脉 2. 无交集A一度人脉 ∩ B一度人脉 有交集 → 二度人脉 3. 无交集A二度人脉 ∩ B一度人脉 有交集 → 三度人脉 4. 以上均无交集 → 标记为「三度」 性能结果复盘整套查询流程数据库请求总数稳定控制在10 次左右完美契合常数级性能约束兼顾响应速度与系统稳定性。 四、架构设计的关键取舍思维度数精度取舍三度以上的人脉关系社交价值极低用户几乎不会通过多层中间人建立联系无需做精细化度数计算统一归类为「三度 」即可排序逻辑取舍用户搜索结果排序并非单纯依赖人脉度数还会结合校友、同事、共同好友亲密度等多维度因子算力场景取舍复杂图遍历、全量关系计算放在离线异步执行在线服务只做简单查询与集合运算是高并发社交系统的通用设计范式。 写在最后社交系统的底层设计从来不是单纯的算法堆砌。共同好友功能靠读多写少场景 缓存兜底实现性能优化六度人脉靠离线预计算规避在线图遍历瓶颈。读懂业务流量特征、认清算法落地边界、做好架构取舍才是后端架构设计的核心精髓。