二、双写最难的不是"搬到近处",是给事件排个先后
边缘节点方案公布后,很多人把它理解成"把服务器搬得离玩家更近一点"。搬到近处确实能压低延迟,但那只是第一阶段。真正卡住整个进度的,是第二步"双写":当同一个世界的状态,允许从中心和一个区域节点同时写入时,系统必须先回答一个问题——两笔几乎同时到达的写,谁在前、谁在后?
这个问题不解决,下沉就只能停在"只读"。所以天工引擎在灰度面板跑稳之后,把接下来这段时间全部投在了排序方案的定稿上,这也是它至今没进入双写的唯一原因。鼎上娱乐这次拿到的,是这套排序思路的工程拆解。
三、为什么本地时钟不可信:先量偏移
最直觉的做法是"按事件发生的时间戳排序"。但区域节点和自己的机器,用的是各自的墙上时钟。实测中,两个试点节点与中心的时钟偏移在 ±40ms 上下波动,即便都走 NTP 校准,也存在几十毫秒的漂移,而且漂移方向不稳定。
40ms 听起来不大,但两场几乎同时的操作,差距常常就在几十毫秒以内。用不可信的时钟排序,等于把"谁先抢到归属"交给了一台没校准的表。所以第一步不是排序,而是承认:墙上时钟不能当判据,它只能用来做粗粒度的日志对齐。
四、不用墙上时钟,那用什么定序
方案的核心是把"定序权"收回到一个地方:每个事件在产生时,先在本地打一个单调递增的序列号(只保证"我这个节点上我比上一条晚",不和别的时间比),再连同节点标识一起送到中心;由中心按到达顺序给出全局序号。玩家看到的"先后",永远是中心给的那个序号,而不是任何设备上的时钟读数。
这就是为什么灰度阶段要先跑两周只读:排序协议只有在全网都用同一套序号口径时才有意义。面板那类只读判定可以先接受"最终一致",写判定不行。
五、两笔"同时"的写,在系统眼里没有同时
回到那个具体问题:玩家甲在区域节点提交一条航段归属,同一瞬间另一个玩家乙在中心提交同一条。物理上它们确实可能真同时发生,但在协议上不存在"同时"——中心只会按自己收到两笔请求的时刻排一个先后,晚到的那笔拿到更大的全局序号。
被排在后面的那笔不会被丢弃,而是进入一次冲突判定:系统会重新读取"在它落地之前世界状态已经变成什么",再决定这笔写是否仍然有效。这就是归属类判定"提交时状态可能已变,需要在中心合流时再校验一次"的由来——校验的对象正是那个全局序号,不是本地时间。
六、幂等:同一事件重复到达,怎么合并成一条
排序之外还有一个更隐蔽的坑:重连时,一个客户端会把断线期间的事件批量补齐,网络抖动又可能让同一事件到达两次。如果每次到达都当新事件处理,世界状态会被同一件事改动多次。
解决方式是幂等:每个事件带一个在本地节点内唯一的序列号,合流时按序列号去重。上一次影子运行暴露过的"两条相同事件在不同节点上序号都从 1 开始",就是这个坑的体现——本地序号只在本节点唯一,一旦跨节点,必须加上节点标识才不会撞。补写、重发、断线重连,都靠这条来兜底。
七、冲突合并:谁能覆盖谁
两笔写指向同一个对象时(比如两个队伍同时申请同一中继站的归属),排序给出先后,但还需要一条合并规则决定结果。当前方案按判定类型分档:
- 先到先得类(归属、夺航占位):以中心全局序号为准,晚到即失败,不做覆盖;
- 最后写赢类(可回退的状态,如面板开关、偏好设置):以最大全局序号为准;
- 只增不减类(分数、进度累计):两笔都累加,不存在覆盖;
- 判罚类(封禁、处罚):永远走中心单点,不下沉、不合并。
把判定分成这四档,双写的合并逻辑才写得完。绝大多数争议,都出在该用"先到先得"的地方误用了"最后写赢"。
八、每 30 秒的世界快照,是排序的安全网
再严密的协议也可能有 bug,所以系统保留了一道兜底:每 30 秒对世界状态做一次全量快照,作为权威参照。任何一次合流结果如果和"上一个快照 + 这之间的有序事件"推导出的状态不一致,就会被标记,严重时触发回退。
快照不是用来实时纠正的(30 秒太粗),而是用来在对账时提供一个不可辩驳的基准线。影子运行阶段那次"注入抖动演练回退线",靠的就是拿快照当尺子,才知道一致率真的跌破了阈值。
九、双写还没开:前置检查清单过到哪一项了
方案写死了双写的两个前置条件:连续一周一致率稳定在 99.9% 以上,以及跨节点事务的顺序方案定稿。到 10 月 30 日,前一项随着灰度面板跑稳正在接近达标,后一项——也就是上面这套排序与合并协议——还在评审收尾。两者都过了,双写才会开始。
这解释了一个常见误解:不是"边缘节点测完了就该切双写",而是"排序协议定稿之前,写操作一律留在中心"。搬机器是体力活,定协议才是那道真正的门槛。
十、半决赛之前不会开双写:时间窗与安全边际
另一个硬约束是赛程。11 月 5 日、6 日的半决赛落在灰度窗口之内,规则已定死:赛事期间边缘节点只做观测,不做主判定,任何自动降级都不在赛程中生效。这意味着双写的启动至少要排到半决赛之后。
理由和观赛方案里"只观测不切主"是一致的:一场 BO7 的判罚争议成本,远高于省下几百毫秒延迟的收益。反过来,赛事两小时的高并发读流量,正是双写之前最需要的一份真实样本——所以这个阶段的最佳策略是"借赛事观测,但绝不在赛事里切换"。
十一、给做同类系统的人:顺序是协议,不是硬件
这一篇最值得复述的一句是:低延迟可以靠把服务器搬近来解决,但"谁先谁后"只能靠协议来解决。时钟、网络、硬件都不会给你一个可信的全序,只有"本地单调序号 + 中心定序 + 分档合并 + 快照兜底"这套组合能给。
如果你也在评估类似的下沉,建议按这个顺序自查:能不能接受墙上时钟不可信、愿不愿意把定序权收回到单点、四类判定能不能清晰归档、以及有没有一个当协议出错时可以依靠的权威基准。这四题答不上来,双写就还不该开。鼎上娱乐会在这套协议定稿、双写真正开始时,再公开一次实测。