Q31: 如何设计好友系统？
核心结论
好友系统看起来是社交功能，实际上是“关系存储加在线感知加互动权限”的组合系统。
真正需要先想清楚的不是界面细节，而是：
- 关系是双向还是单向
- 在线状态怎么传播
- 黑名单和权限怎么裁决
- 跨服和分区后关系如何保持
如果这些边界没定义清楚，后面功能越堆越乱。
一、先定义关系类型
好友系统通常不止一种关系。
常见包括：
- 双向好友
- 单向关注
- 黑名单
- 特殊关系，如亲密、师徒、CP
这些关系的存储模型和通知规则都不一样，不应混成一套模糊逻辑。
二、好友系统真正的核心能力
通常至少包括：
- 建立和解除关系
- 查询好友列表
- 在线状态查看
- 私聊、邀请、传送等互动入口
- 黑名单拦截
表面上是“加好友”，本质上是社交关系和权限判定。
三、关系数据怎么建模
最常见的是关系表，而不是把好友列表整个塞进角色主档。
原因很简单：
- 关系天然是多对多
- 需要单独查询和分页
- 需要附带备注、分组、亲密度等信息
双向好友通常有两种建模方式：
- 一条记录表示一对关系
- 两条方向性记录分别表示双方视角
具体怎么选，取决于查询与维护习惯。
四、在线状态为什么是难点
好友系统的静态关系不难，真正频繁变化的是在线状态。
难点在于：
- 玩家上下线频繁
- 可能跨网关、跨服
- 状态推送容易形成扇出
所以很多系统会做分层：
- 关系数据走持久层
- 在线状态走缓存或会话层
- 通知按订阅或增量更新
五、不要把好友系统做成“全量推送系统”
当好友数很多时，如果每次状态变化都向所有好友全量推送，成本会很高。
更合理的方式通常是：
- 登录时拉取一份摘要
- 上下线只推送增量变化
- 长期不互动的关系降低更新频率或延迟查询
六、黑名单和权限必须优先级更高
很多系统把黑名单当附加功能，这很危险。
更合理的原则是：
- 黑名单优先于好友关系
- 被拉黑后应阻断私聊、邀请、申请等入口
- 某些展示信息也应受限
否则逻辑会出现互相冲突。
七、跨服场景要额外考虑什么
如果游戏有跨服、分区或多场景集群，好友系统通常需要解决：
- 角色标识全局唯一
- 在线状态来源统一
- 跨服私聊和邀请路由
- 离线消息或提醒
这时好友系统就不再只是单服表结构问题，而是社交中台问题。
八、工程上更稳妥的组合
一个常见做法是：
- 持久层保存好友关系和备注等静态数据
- Redis 或在线服务保存在线状态摘要
- 社交服务统一处理申请、黑名单、邀请、私聊路由
这样主游戏逻辑不会被社交状态拖得太重。
九、常见误区
1. 好友系统只是一个关系表
不够。在线状态、权限控制和跨服路由往往更复杂。
2. 在线状态直接查角色进程就行
在分布式环境下，这会很重，也不利于统一聚合。
3. 黑名单只是聊天过滤
通常不止。它还影响邀请、申请、查看资料等入口。
参考资料
- 各类在线游戏社交系统与在线状态服务实践资料