9.3 游戏同步与状态存档

9.3 游戏同步与状态存档：高频广播与二进制治理

本节摘要：游戏现场把两条极端约束叠加在一起——同步广播的百毫秒级高频小消息（编码开销的极限压榨）与存档回放的年级长周期二进制治理（演进规则的极限拉伸）。本节评估 protobuf 在高频同步上的真实开销边界、给出与位编码混编的方案，并设计存档的版本演进策略。读完你应当能裁决"游戏里哪些数据该用 protobuf、哪些不该"。

第三现场。前两个现场的约束是外部的（网络、版本），游戏现场的约束来自数据本身——同步消息小到极致、存档周期长到极致，protobuf 的甜区与边界在这里同时暴露。

高频同步：开销的极限压榨

帧同步或状态同步的游戏里，同步消息的典型形状是：每玩家每 tick（百毫秒级）一条几十到几百字节的消息，广播给房间内全部玩家。乘法残酷：100 人房间 × 10 tick 每秒 × 每条 100 字节 = 每秒 100KB 的广播流量、每秒上千次的序列化调用。第 7.1 节的基准方法在这里的用法：测的不是单条耗时而是"每 tick 全房间序列化的 CPU 预算占比"——单条 2 微秒乘上一万次调用，就是每秒 20 毫秒的 CPU，对同机部署逻辑的服务器是不可忽视的占比。

protobuf 在这个形状下的开销账本（第 3 章机理的应用题）：tag 开销占比畸高——一条 30 字节的消息里可能有 12 个字段，每个字段 1 到 2 字节 tag，包装占比 40% 以上；这正是 7.2 节陷阱的极端化。两条出路：

出路一：字段级的极限优化。 全部高频字段进热区编号（1–15）；坐标用 sint32（游戏坐标常带正负）；把同一实体的多个小字段合并进 packed repeated 或单条位域字段（一个 uint32 的 32 个比特装 32 个布尔状态——但注意 7.2 节反向纪律：位域是字节级优化语义级灾难的典型案例，只用于"32 个独立布尔"这种语义天然原子化的场景）。

出路二：混编——protobuf 做外层，位编码做内层。 同步信封用 protobuf（路由、房间、序列号、玩家 ID 等结构化头部），载荷是手写位流（每实体固定比特布局，客户端服务端共享同一份布局常量）：

message FrameSnapshot {
  int32 tick = 1;
  int32 room_seq = 2;
  bytes payloads = 3;    // 手写位流：每实体 N 比特定长布局
}
​

位流载荷的体积可比等价 protobuf 编码小 40–70%（无 tag、无长度前缀、布尔压到 1 比特），代价是彻底放弃自描述与演进自由——布局常量的任何变更都是硬同步（客户端服务端必须同版本）。裁决判据：载荷字段集合是否已冻结？冻结（如成熟玩法的物理状态）→ 位流合理；仍在演进（新技能新状态持续加）→ 留在 protobuf，用出路一压。

图 9-2 混编方案：protobuf 信封与位流载荷的分工

状态存档：长周期二进制治理

存档的约束换轴：数据生命周期以年计（玩家的存档要跨游戏的大版本存活），读写频率低（存档时刻序列化、读档时刻反序列化），体积敏感（云端存档的存储成本直接乘玩家数）。

protobuf 做存档格式的优势面：跨语言（存档生成工具、云存档校验服务、客户端三方可共享契约）；未知字段机制让"新版本游戏读旧存档"天然安全（旧存档里没有的新字段缺省、旧存档里多出的实验字段被保留）——第 5 章全部演进规则原样适用。

风险面必须点名两条。其一，存档 schema 的版本冻结纪律：存档契约是"写一次就要活十年"的契约，第 5.2 节的所有"可协商"级变更（收位、enum 删值）在存档上下文里应一律按"禁止"对待——存档没有灰度窗口，玩家离线三年后的读档必须成功。其二，well-known 类型的诱惑：存档里放 Struct 存"策划配置的自由扩展"（6.3 节场景）要警惕——三年后没人记得自由结构里装过什么，Struct 存档的治理成本随时间指数上升；扩展点宁可走正式的 proto 版本化。

回放系统：两约束的交汇点

回放（录像、战报）是高频同步与长存档的交汇：录制时以同步消息的频率写入，回放时按序重放，保存周期同存档。protobuf 做回放格式的工程要点：录制的是原始字节流而非解码后的对象——回放头部用 protobuf 描述元信息（版本、时长、参与者），每帧的同步消息按录制原样追加（长度前缀分隔）。回放兼容策略：老版本游戏跳过不认识的帧（wire type 盲跳保证安全）而不是报错——"回放能放但新单位显示为占位"远好于"回放打不开"。

实战案例：一个 SLG 的同步层重构

背景：一款 50 人同屏的 SLG，状态同步原本全 protobuf，大房间（满编）时服务器序列化 CPU 占比 18%，触发优化立项。操作：第一步按 7.1 节方法建基准（满编房间真实快照做样本），确认开销构成——tag 与长度前缀占编码体积 52%（字段数量多、单字段值小，7.2 节陷阱极端化）；第二步按字段集合冻结度拆分——单位战斗状态字段集合已冻结两年，改位流内层（每实体 24 比特定长布局）；建筑与经济字段仍在演进，留 protobuf 并做热区编号重排；第三步信封混编（本节方案），回放格式同步改造（帧字节原样录制）；第四步复测与灰度。结果：同步消息平均体积从 186 字节降到 74 字节，序列化 CPU 占比降到 6%；战斗位流布局常量进版本控制并配"客户端服务端布局指纹一致性"的启动校验（布局漂移即拒连，把混编的版本耦合显式化）。解读：这次重构的裁决全程沿本节判据走——冻结的进位流、演进的留 protobuf、混编的版本耦合用启动校验兜底；"该不该用 protobuf"在游戏现场的正确问法是逐数据域地问，而不是全游戏统一答案。变式：MOBA 类技能字段迭代频繁的品类，位流占比会显著缩水——此时优化的重心转向字段级手段（packed、位域布尔、编号重排），protobuf 占比保持高位是正确的形态。

本节要点回顾

• 开销乘法：高频广播的预算口径是"每 tick 全房间序列化 CPU 占比"，不是单条耗时；
• 极限优化：全热区、sint 坐标、位域原子布尔——但位域是语义级灾难的高危区，仅限天然原子字段；
• 混编判据：字段集合冻结走位流内层、仍在演进留 protobuf、版本耦合用启动指纹校验显式化；
• 存档纪律从严：十年生命周期的契约里"可协商"级变更按"禁止"对待，Struct 扩展点慎用；
• 回放按数据域问：正确问法是逐域裁决 protobuf 边界，不是全游戏统一答案。

游戏现场收工。最后一个现场的时间尺度再拉长三个数量级：大数据管道的年级留存与 schema 治理。