同步模型

Category

server / sync 子树。节点定位：同步模型的本质是裁决权——权威状态同步、输入锁步、混合方案按问题匹配，不按「发输入还是发状态」分类。

Definition

同步模型回答的不是一个抽象理论问题，而是这局战斗到底怎样收敛成一份所有参与者都能接受、平台也能追责的结果。你发的是输入、状态、事件还是快照，只是表层差异；真正有分量的，是裁决权在谁手里，一致性何时建立，客户端可以先做多少，本地和服务端各承担哪些复杂度。

Problem

同步模型不定就开工，全按直觉走：裁决权在谁、一致性何时建立、客户端可先做多少、复杂度怎么分——这四问不答，发输入还是发状态只是表层，团队会在误判里反复推倒重来。

为什么同步模型必须先定

同步模型不是后期可以随手替换的实现细节。它会影响几乎所有核心系统：

• 技能是否依赖严格帧号和确定性。
• 角色移动是否允许本地前馈和纠正。
• Buff 与属性系统能否在客户端部分模拟。
• 回放记录输入还是记录状态。
• 断线重连是拉快照还是逐帧追赶。
• 反作弊是靠权威裁决还是靠事后稽核。

因此，同步模型选得越晚，返工范围就越大。

不要只按“发输入还是发状态”分类

更有用的理解方式，是从几组更硬的维度同时看同步模型：

• 权威归属：最终结果由客户端、房主、协调服务器还是权威服务器决定。
• 共享粒度：同步的是整包状态、关键事件、输入序列还是周期快照。
• 一致性时机：输入发生时立即达成、延后若干帧达成，还是先本地演后服务端收敛。
• 客户端职责：只是显示权威结果，还是要参与完整模拟。
• 作弊面：客户端能伪造多少，服务端能验证多少。

这样看以后，你会发现所谓“同步模型”并不是三个标签，而是一组工程取舍。

常见模型一：服务端权威状态同步

这是今天最常见的主流做法。服务端持有权威世界状态，客户端发送输入或操作请求，服务端计算后再广播关键结果或状态更新。客户端通常会做有限预测和插值，但不会拥有最终裁决权。

它的优点很明确：

• 反作弊和仲裁更容易建立。
• 客户端之间不需要严格确定性。
• 重连更容易走快照恢复。
• 内容团队更容易接受“服务器说了算”的组织方式。

它的代价也同样直接：

• 本地手感必须靠预测、补偿和插值修出来。
• 广播压力和状态压缩成本较高。
• 频繁纠正时体验可能很差。
• 服务端逻辑和网络链路压力较大。

大量 ARPG、MMO、射击和多数强调服务端权威的联网项目，都更接近这一类。

常见模型二：输入锁步 / 帧同步

这类模型的核心思想不是同步状态，而是同步输入。各参与方在第 N 帧拿到一致输入，然后各自按统一逻辑推进到第 N + 1 帧。只要输入一致、顺序一致、模拟一致，最终状态就应该一致。

它的优点通常是：

• 带宽更可控。
• 理论上一致性和回放更自然。
• 关键博弈更容易围绕同一帧号表达。
• 很多争议都能被还原成“第 N 帧输入和状态是否一致”。

它的代价也很重：

• 对确定性要求极高。
• 任一参与者掉队都可能拖慢整局。
• 重连、追帧、暂停、默认输入和托管都必须提前设计。
• 客户端问题更容易直接影响局内一致性。

帧同步不是“更高级”，而是把复杂度从状态广播转移到了时间组织和确定性控制上。

常见模型三：混合方案

真实项目里，最常见的并不是纯状态同步或纯锁步，而是混合式方案。常见混法包括：

• 核心战斗对象按帧或按事件收敛，外围对象走状态同步。
• 输入先本地前馈，关键结果再服务端修正。
• 投射物、技能、命中按权威逻辑算，移动和动画先本地表现。
• 房间内主战斗走帧同步，房间外外围系统走普通请求响应。

混合方案的价值是现实，它承认不同对象、不同玩法、不同链路的容错需求并不一样。它的风险也同样现实：如果边界没划清，系统最后会同时承担两套模型的坏处。

没有“最强模型”，只有问题匹配

如果按常见项目类型粗看，同步模型通常会这样倾向：

• 强实时竞技、RTS、部分格斗和少数房间制产品，更容易被帧同步或接近锁步的方案吸引。
• MMO、ARPG、射击、大部分多人在线项目，更容易落到服务端权威状态同步。
• 复杂混合项目，往往在局内外、对象层级、技能层级上使用不同同步策略。

决定因素通常不是技术偏好，而是下面这些更硬的事实：

• 玩家对即时手感的容忍边界。
• 对公平性和可追责的要求。
• 客户端作弊面是否可接受。
• 团队是否有能力长期维护确定性和调试工具。
• 断线重连、回放、观战和赛事这些配套能力是否重要。

一个更有用的比较视角

维度	服务端权威状态同步	帧同步 / 输入锁步	混合方案
裁决权	服务端集中	参与方共享或服务器协调	分层分对象
带宽形态	状态或事件广播较多	输入包较轻	混合
确定性要求	中等	很高	局部很高
本地手感	依赖预测补偿	依赖领先帧或局部前馈	依赖边界设计
重连恢复	快照更自然	需要快照、追帧、默认输入	视子系统而定
回放实现	状态与事件回放更常见	输入回放更自然	通常两者并用
作弊面	更易控制	更难控制	取决于权威边界

这个表的意义不是给出标准答案，而是提醒你：同步模型的差异体现在整条工程链路上，而不是只体现在网络包长什么样。

为什么很多团队会误判

同步模型最容易被误判的原因，是团队只看到了某一个局部收益：

• 看到帧同步省带宽，却没看到确定性和重连成本。
• 看到服务端权威易反作弊，却没看到预测和纠正的体验成本。
• 看到混合方案看起来兼得，却没看到边界设计和调试成本。

如果不把技能系统、断线恢复、回放、观战、托管、外挂和工具链一起纳入考量，最后的模型判断通常会偏。

常见误区

• 把同步模型看成后期可以替换的实现细节。
• 只用“发输入还是发状态”来理解同步模型，忽略裁决权、恢复语义和作弊面。
• 在没有日志、状态哈希、快照和可视化工具的前提下上高复杂度方案。

同步模型真正要先定的，不是名词，而是裁决哲学、恢复语义和复杂度落点。

实战案例：一次「帧同步省了带宽，重连和争议反而爆了」的同步模型误判排查

案例为教学示例（非摘自真实项目），数字经过取整简化。它把本页「不要只按『发输入还是发状态』分类」「常见模型三：混合方案」「为什么很多团队会误判」用到深水区：广播流量确实降了，重连和争议成本却涨了——这是同步模型只看到局部收益的排查，也是「怎样把模型选型按整条工程链路来评估」的完整展开。

背景与现象：某房间制实时对战（4v4，类 RTS 与格斗混合玩法），团队为省带宽选帧同步，广播流量比原状态同步方案降了 64%。上线一个月后，重连失败率 8%、争议工单日 600 单、状态分叉每周 3 次——省下的带宽成本，从另外三个口子成倍还了回去。

第一步：现象与口径——把省下的和涨上的分开记

带宽口径：广播流量降 64%，单局带宽从 48 KB/s 降到 17 KB/s，这部分收益是真的。

重连口径：重连失败率 8%，失败会话集中在落后超过 900 帧的场景；成功重连的平均恢复耗时 41 秒。

争议口径：日 600 单争议里，63% 是「结果对不上」，客户端与服务端状态不一致但双方都认为自己正常。

第二步：分层归因——按本页成本清单逐项排查

重连失败 8%  归因
  无默认输入与超时策略，整局等掉线玩家     55%  →  4.4 个百分点
  无周期检查点，重连只能逐帧补             30%  →  2.4 个百分点
  无状态哈希，分叉不自知只能重开           15%  →  1.2 个百分点

逐项比对：帧同步依赖清单里的默认输入、检查点、状态哈希三项都没建。掉线玩家不提交输入，服务器不填充默认输入，整局卡在等待上，其他人跟着被拖；重连客户端从断点逐帧补，落后 900 帧以上根本追不上；分叉发生后没有哈希校验，3 次每周的分叉全靠玩家录像发现。

第三步：根因——只看到帧同步省带宽，没看到确定性与重连成本

选型时只算了带宽这一笔，没有把技能系统、断线恢复、回放、争议处理一起纳入评估。帧同步把复杂度从状态广播转移到了时间组织和确定性控制上，而团队没有对应的默认输入、检查点、哈希工具链——这正是本页说的「看到帧同步省带宽，却没看到确定性和重连成本」。

第四步：处置与回填——补齐配套，再划清混合边界

1. 补默认输入与超时策略：某玩家第 N 帧输入超时后填默认输入（空操作或保持方向），整局不再等待。
2. 周期检查点 + 重连走快照：每 300 帧生成一次检查点，重连优先加载最近检查点，再追一小段增量帧。
3. 状态哈希与分叉定位：每 60 帧计算关键状态哈希，房间内比对，发现分叉后定位最早异常帧。
4. 划混合边界：聊天、公告、活动刷新等外围系统移出帧同步主链路，走请求响应，不再占用帧包。

复核账：重连失败率 8% → 0.6%；争议工单日 600 单 → 80 单；状态分叉每周 3 次 → 0 次；带宽仍保持降幅 60% 以上——配套补齐后，帧同步的收益才真正落袋。

回填清单：

回填项	动作	回填处
模型四问	选型时按裁决权、一致性时机、客户端职责、作弊面四问逐条评估，不看单一收益	不要只按“发输入还是发状态”分类
帧同步依赖清单	默认输入、输入缓冲、状态哈希、检查点、追帧策略作为上线前置项逐条验收	常见模型二：输入锁步 / 帧同步
混合边界	核心战斗走帧同步，外围系统走请求响应，边界写进架构图	常见模型三：混合方案
误判清单	选型评审附「省了什么、涨了什么」两栏账，重连与争议成本必须列进去	为什么很多团队会误判

案例的三个教训

1. 同步模型选型要算整条链路的账，不能只看带宽一笔。省下 64% 广播流量，换来 8% 重连失败和日 600 单争议——局部收益不是收益。
2. 复杂度不会消失，只会转移。帧同步把状态广播的复杂度换成了确定性和重连的复杂度，团队没有对应工具链，转移过来的成本就还不起。
3. 配套缺失的模型，收益会被自身缺口吃掉。默认输入、检查点、状态哈希补齐后，帧同步的带宽收益才留得住——模型和配套是一体的。

Used By

同步模型选型评审；新战斗玩法的技术评估。

• Colyseus（commit e620123）：权威状态同步的落地形态——README 定位「Authoritative Multiplayer Framework for Node.js」（README.md:21），状态经 schema delta 统一产出增量后广播（packages/core/src/Room.ts:1374-1393），同一 buffer 一次编码 N 路发送（Room.ts:430-434、:1411-1414）

Related

关系链：先定模型 → 分类视角 → 权威状态 → 锁步 → 混合 → 问题匹配。上游：sync/01（时间模型）。下游：sync/03（帧同步展开）、sync/05（预测补偿）。

Reference

本页为工程经验归纳；页内实战案例为教学示例（数字取整简化）。