路线 B｜C++ Linux 游戏服务端

B6｜Game Server Architecture：登录、房间、匹配与同步

适用基础： B2～B5 目标： 能把玩家、房间和游戏状态放入明确的权威服务模型。

---

一、服务边界

Login：身份和令牌
Gateway：连接、协议和路由
Game：玩家状态和玩法规则
Room/Match：匹配与房间生命周期
Chat/Ranking：独立可扩展能力

边界按状态 owner 划分，不按“代码方便”共享可变对象。

Login 的令牌证明身份，Gateway 维护连接和路由，Game 保存长期在线业务状态，Room 保存短生命周期对局状态，Match 只负责形成匹配结果。把所有功能拆服务并不天然更好；当团队和负载不足时，清晰模块化的单体比大量 RPC 更容易保证一致性。

二、玩家 Session 与存档

登录令牌、连接 session、玩家状态和持久化版本必须分开。断线重连要防止旧连接写入新状态，存档更新使用版本或乐观锁检测覆盖。

玩家在线状态通常由某个 Game 实例独占，Gateway 只保存路由。顶号、重连和迁移都要通过版本递增切断旧连接；旧异步回调必须携带旧版本并被拒绝。存档是长期事实，在线对象是工作副本，两者需要明确保存点和崩溃恢复策略。

三、房间状态机

Waiting → Matching → Ready → Playing → Settling → Closed

每个转换写明触发者、超时、可重入性和持久化动作。房间关闭必须清理玩家引用、Timer、广播队列和匹配索引。

房间内部常采用单线程/Actor 式 owner，让同一房间事件串行处理，减少锁和状态竞态。不同房间可以分布在多个线程或进程。跨房间操作不能直接共享对象，应通过消息和版本化结果交互。

四、状态同步与权威性

帧同步传输输入并要求各端确定性，适合规则固定但对浮点、随机数和版本一致性敏感；状态同步传输服务器权威快照或增量，客户端可预测和插值，但要处理校正、快照丢失和带宽。客户端是不可信的，服务器验证输入、时间、资源和频率。选择同步模型要结合玩法、延迟、作弊面和回放需求。

五、匹配与排行榜

匹配队列要有超时、取消和重复请求处理；排行榜要定义分数事实、并发更新、分页快照和作弊检测，不能把 Redis 排序结果直接当永久事实。

匹配不是只按分数排序，还要在等待时间、地区延迟、队伍结构、段位范围和重复对手之间取舍。等待越久可以逐步放宽条件，但必须记录匹配版本，避免取消后旧结果仍然建房。

排行榜需要区分实时榜、结算榜和历史榜。实时榜可使用 Sorted Set，结算时需要快照或版本冻结，奖励发放使用幂等批次；否则分数在分页或结算期间变化会造成重复和遗漏。

六、房间结算与恢复

房间状态机必须明确谁拥有状态、哪些转换幂等、超时后如何结算、进程重启如何恢复。结算使用房间版本或结算幂等键，避免重复发奖；玩家断线不一定立即离房，取决于重连窗口和玩法语义。

七、练习与答案

1. 为什么结算必须幂等？

网络重试、进程恢复或客户端重复提交都可能触发多次；幂等键和结算版本保证奖励、扣费只应用一次。

2. 客户端预测能否改变服务器权威？

不能。预测只是表现优化，服务器仍验证输入并发布权威结果。

八、阶段输出

提交服务边界图、玩家/房间状态机、协议版本、断线重连时序和非法输入测试报告。