YoYouFun 笔记

外观

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

B7｜Production Project：Cocos 客户端与 C++ 服务端闭环 ​

适用基础： B1～B6、路线 A 的客户端理解 目标： 完成一个可部署、可观测、可压测和可恢复的最小线上系统。

一、项目范围 ​

text
Cocos 客户端
→ Gateway（TCP/WebSocket）
→ Login/Game/Room 服务
→ MySQL 玩家数据
→ Redis 会话、缓存和排行榜

功能至少包括登录、心跳、断线重连、玩家存档、房间、匹配、排行榜、日志、配置、健康检查、部署、压测和 Crash 排查。

二、系统架构与数据流 ​

text
Cocos 登录请求
→ Gateway 鉴权和限流
→ Login 签发 session/token
→ Game 维护玩家权威状态
→ MySQL 持久化事实
→ Redis 缓存和排行榜
→ Room 运行短生命周期玩法

Gateway 不拥有玩家玩法状态，Game 不直接相信客户端字段，数据库不承担实时 Tick。每个状态只有一个主要 owner，跨服务使用协议和幂等事件交换。

三、迭代顺序 ​

  1. 单进程协议回显和客户端连接。
  2. 登录与 session。
  3. 玩家数据和幂等存档。
  4. 房间状态机。
  5. Redis 缓存和排行榜。
  6. 拆分 Gateway/Game。
  7. systemd、监控、压测和故障演练。

每一步都保留协议版本、数据库迁移、回滚和回归测试，不在最后才补运维。

四、协议契约 ​

每条消息定义 type、version、requestId、session、payload、错误码和最大长度。客户端显示错误不能替代服务端日志；敏感字段不进入普通日志。

协议升级要明确向前/向后兼容。新增可选字段通常容易兼容，改变字段语义或复用旧类型号风险很高。服务端应在握手阶段记录客户端版本和能力，不能假设所有在线客户端同时升级。

五、可观测性 ​

统一 trace ID，记录连接、请求、DB、Redis、房间和结算阶段。指标包括连接数、在线玩家、请求 P99、错误率、队列、Tick、缓存命中、慢查询、内存、CPU 和重连率。

服务目标应从玩家体验反推，例如登录成功率、匹配等待 P95、房间 Tick 长帧率和结算正确率。CPU 只是原因指标，不是最终业务目标。告警必须有负责人、阈值依据和处置入口，避免产生无人处理的噪音。

六、部署与安全 ​

使用最小权限用户、私网数据库、密钥注入、UFW/反向代理和备份策略。生产服务器事实必须写入项目统一总账，不在课程仓库提交密码、Token、私钥或生产 .env。

认证令牌要有签发者、有效期、撤销或版本机制；客户端输入限制长度、频率和状态转换。防作弊不是只检查数值范围，还要验证操作时序、资源来源和服务器权威规则。数据库备份只有完成恢复演练才算有效。

七、故障处理知识 ​

text
Gateway 重启
Redis 暂时不可用
MySQL 慢查询
网络丢包和延迟
Game 进程崩溃
客户端重复请求

每次演练记录检测时间、影响范围、恢复动作、数据一致性和后续修复，不以“服务重启了”作为完整结论。

八、性能与容量 ​

建立连接数、消息率、房间数、DB QPS、Redis QPS 和 CPU/内存的容量模型；压测逐步升压，区分单机极限、依赖极限和业务 SLA。保留火焰图、慢查询和网络指标。

九、最终验收 ​

text
功能：主流程和异常流程通过
正确性：重复/乱序/断线不重复扣费或发奖
性能：明确并达到目标 P95/P99
可靠性：重启和依赖故障可恢复
安全：鉴权、限流、输入校验和密钥隔离
运维：部署、日志、监控、备份和回滚可执行

十、路线 B 总结 ​

B1 解决 Linux 进程和服务，B2 解决网络，B3 组织服务工程，B4 处理数据，B5 处理分布式故障，B6 建立游戏领域模型，B7 把它们串成可运行系统。