posts
在线联机原型第 33 章导航：社交关系与好友推荐
本章把玩家之间的关注、好友、组队、交易记录抽象成一张可查询、可推荐、可实时感知在线的社交图。它要回答的不是「怎么加好友」，而是「当这张图有几千万条边时，怎么在几十毫秒内推荐出三个可能愿意一起玩的人」。本页给出第 33 章社交关系与好友推荐（Social Graph & Recommendation）的定位、六个核心验证目标（Presence Service、图存储与查询、推荐算法、双向关系一致性、隐私与黑名单、在线状态扇出）、推荐技术栈与真实文章入口。
第 33 章处理的是一类看起来简单、做起来很快失控的需求：好友与推荐。加入好友本身只是一条边，但这条边要和在线状态、组队邀请、隐私设置、黑名单、跨服身份全部联动，一旦玩家规模上来，任何一次「查一下共同好友」都可能变成全表扫描。这一章把社交关系显式建模成图，先验证图上的读写与推荐，再叠加实时在线状态。它适合已经做完大厅与匹配、准备把「和谁玩」这件事做深的产品与后端，也适合想判断图数据库到底该不该引入的架构同学。
本章定位
| 项目 | 内容 |
|---|
| 全集层数 | 第 4 层（概念原型层） |
| 难度梯度 | 进阶。关系建模本身不难，难的是图查询与在线状态的一致性，建议先完成第 20 章社交大厅与第 23 章跨服战 |
| 前置章节 | 第 12 章团队占点、第 20 章社交大厅、第 23 章跨服战系统、第 32 章玩家驱动经济系统 |
| 后续章节 | 第 34 章联盟战争、第 47 章多语言实时语音协作、第 53 章自组织联盟与自治经济 |
| 原型代号 | proto-33-社交关系与好友推荐 |
| 形态 | Graph 推荐型，单篇文章的完整 PRD，覆盖架构、状态机、接口与验证清单 |
这一章把「关系」和「状态」明确拆成两套系统：图存储负责慢变的边，Presence 负责快变的在线状态。混在一起是社交系统最常见的性能陷阱。
核心验证目标
| 验证点 | 要回答的问题 | 判定标准 |
|---|
| Presence Service | 在线、组队、对局中三种状态如何实时上报与下发 | 状态变更在百毫秒级到达好友端 |
| 图存储与查询 | 好友、共同好友、二度关系如何高效查询 | 二度关系查询在目标数据量下满足延迟预算 |
| 推荐算法 | 用什么信号推荐「可能认识的人」与「可能合得来的人」 | 推荐结果可解释、可离线评估、可灰度 |
| 双向关系一致性 | 好友关系被一方删除时另一方的视图如何收敛 | 不出现单向好友残留 |
| 隐私与黑名单 | 拒绝推荐、拒绝邀请、屏蔽某人如何生效 | 黑名单在所有入口生效且不可绕过 |
| 在线状态扇出 | 一个玩家上线要通知多少好友 | 扇出量可控，可分级或批量合并 |
技术栈建议
- 语言：Go、Rust、Python 三者任选，图查询与在线状态服务建议用 Go 或 Rust。
- 协议：WebSocket over HTTPS 推送在线状态，gRPC 承载图查询与推荐调用。
- 存储：图数据库承载关系边与二度查询；Redis 保存在线状态与最近活跃；PostgreSQL 保存好友申请的强一致记录与隐私设置。
- 推荐：离线特征与在线召回分离，召回结果缓存，排序可先用简单规则再逐步引入模型。
- 可观测：关系写入延迟、图查询 P99、状态扇出量、黑名单命中率。
本章文章
这篇文章内部按八个部分展开，阅读时可以直接跳到关心的那一段：
| PRD 小节 | 内容 |
|---|
| 一、概述 | Graph 推荐的一句话定义与本章要验证的能力 |
| 二、核心玩法与系统目标 | 产品体验、功能目标与四类验证重点 |
| 三、系统架构设计 | Gateway、推荐 Service、State Manager、Event Bus、Persistence 五层划分 |
| 四、功能模块详解 | 基础通信、状态同步、输入校验、日志与监控 |
| 五、状态机与流程图 | 好友申请状态机与状态广播的时序图 |
| 六、事件与接口定义 | WebSocket 消息类型与 REST 会话接口 |
| 七、性能指标与优化 | 延迟、并发、吞吐、内存四项目标值 |
| 八、验证清单 | 可直接当作验收用例的五条清单 |
与相邻章节的关系
相关专题