二、影子运行第一天:结果不算数,但每条差异都要解释
从 10 月 28 日 20:00 开始,天工引擎把两个区域节点接上了同一路事件流,进入「影子运行」:节点自己算一遍结果,但不采用、不写回比赛数据,只把两份结果摆在一起对账。到 10 月 29 日晚上,第一份完整的影子报表出来了。
公开的部分是这些数字:采集窗口内共 1.8 万条事件,两份结果完全一致的比例是 99.97%,差异 5 条;事件从中心复制到边缘的滞后中位数 340ms;按三段预算测得的节点内端到端时间,P95 是 1.3 秒,而同一批数据在纯中心模式下的 P95 是 2.1 秒。
需要强调一句:影子阶段的一切数字都不影响任何玩家的实况体验。它的唯一目的,是在真正的流量切过去之前,把「会怎么错」先错一遍。
三、一致率怎么算:99.97% 的分母是什么
「一致」的定义写得比想象中严格:不只是最终结论相同,还要求三个字段逐项相同——事件类型、涉及对象编号、时间戳落在同一档位。任何一个字段不同,就记为一次差异。
分母也不是全部事件。以下三类被排除在统计之外:中心侧本身判定为无效的包、玩家在重连瞬间批量补齐的历史事件、以及跨窗口边界的合并事件。这三类之所以排除,是因为它们的正确参照系不同:历史补齐按原始时间戳比较会永远不一致,必须按到达顺序比较。
5 条差异分布在两个位置:3 条出现在采集窗口的边界(一次维护重连),2 条是同一类事件的序号在不同节点上从 1 开始编号。后者是典型的幂等问题,不是判定逻辑错。前者到今天还没结论,但已经被归类为「可解释但不影响结果」。
四、三段预算的实测:260 / 520 / 130 毫秒
0.9 秒的断流影响目标被拆成三段:节点内判定 300ms、回传中心 400ms、中心合流 200ms。第一天实测落在 260 / 520 / 130 毫秒,合计 910ms。
| 分段 | 预算 | 首日 P95 | 差异 |
|---|---|---|---|
| 节点内判定 | 300ms | 260ms | 达标 |
| 回传中心 | 400ms | 520ms | 超 120ms |
| 中心合流 | 200ms | 130ms | 达标 |
| 合计 | 900ms | 910ms | 在容忍内 |
唯一超预算的是回传这一段。原因并不复杂:两个试点节点的公网出口在晚高峰有拥塞,400ms 是按白天样本定的。这个偏差暂时不调整预算,而是继续观察一整周,因为把预算改成一个更容易达成的数字,只会让后面的判断失去参照。
五、复制滞后 340ms:为什么面板能吃下,判罚吃不下
340ms 的滞后,对不同类型的判定意味着完全不同的事。
对观赛面板,滞后只是"画面慢一点":玩家看到的是 0.34 秒前的地图状态,和直播推流的 15 秒延迟相比可以忽略。对归属与进度类的只读判定,滞后的影响是"提交时状态可能已经变了",这需要在中心合流时再做一次校验,已经设计在合流的 200ms 里。对判罚,340ms 是不可接受的——判罚要求的是事件发生瞬间的世界状态,而不是"最近一次同步的状态",任何补偿逻辑都必须等完整事件到齐,不能靠边缘节点的旧数据推断。
这就是灰度顺序的根据:先面板,再归属,判罚放最后,而且即使上了边缘也必须保留中心的 250ms 判罚帧。
六、回退线一次没触发,但它在第一天就被演练过
方案里写的回退线是:任一试点节点连续 10 分钟一致率低于 99.5%,该节点自动退回中心模式。第一天没有真实触发,因为影子阶段的结果本来就不采用。
但触发条件被人为演练了一次:在采集侧注入一段抖动,让一致率跌到 99.2% 并维持 11 分钟,观察标记、告警与切回是否按预期发生。演练结果是自动降级在 11 分 40 秒触发,中心侧收到标记后 2 秒内完成回退。多出来的 40 秒来自抖动注入本身的时间戳误差,不是判定的问题。
这类演练的价值在于:等真出事时,没人需要临时判断"现在是不是该切"。
七、第一天暴露的两个问题:补齐顺序与移动端节流
第一个问题是重连补齐的顺序。玩家断线 20 秒后重连,事件在中心按到达顺序补齐,在边缘则可能因为缓存分区而按分区顺序补齐。两种顺序在面板上看起来一样,但在"同一毫秒两个事件"的比较里会给出不同结果。目前的做法是补齐统一按中心顺序,边缘只接受,不再自行排序。
第二个问题是移动端的节流。部分手机上浏览器会把后台标签的定时器降频,导致面板上报的时间戳明显滞后。影子阶段这类偏差只是统计噪音,可真实切流之后,它会影响"谁先提交"的排序。方案里加了一条:移动端上报使用服务端接收时间,而不是本地时间。
八、档位、结算、封禁:今天仍然全部在中心
需要说清楚的是,第一天的所有测试都不涉及这三类判定。它们在方案里被明确划为不下沉范围:结算与封禁是跨全局的判定,档位需要所有分区数据齐了才能计算。哪怕只是读,把它们放到区域节点上也要多绕一层一致性验证。
不过影子阶段给这三类带来了一个副产品:所有事件的时间戳现在都必须能对上同一套窗口对齐口径。这套口径过去只在结算脚本里存在,现在被抽成了公共模块,后面 11 月 1 日的结算夜会第一次用它跑完整批次。
九、下一步:下周开始真实灰度,双写仍看 11 月中旬
按照公布的时间表,影子运行持续一到两周,之后进入真实灰度:把观赛面板与只读的地图状态查询切到边缘节点,写操作仍在中心。第一天的数据支持按原计划推进,但需要再看几天晚高峰样本。
双写阶段(边缘与中心同时写,以中心为准)预计 11 月中旬开始,前置条件有两个:连续一周一致率稳定在 99.9% 以上,以及跨节点事务的顺序方案定稿。第二个条件目前还没有结论,两笔几乎同时的写请求怎么排序,是这个阶段最难的一部分,也是很多人以为"下沉"就等于是把服务器搬近的原因所在。
十、半决赛期间的特别约束:只观测,不切主
11 月 5 日与 6 日的半决赛,恰好在灰度窗口之内。规则已经定死:赛事期间边缘节点只做观测,不做主判定,任何自动降级都不会在赛程中生效。
理由不难理解:一场 BO7 的判罚争议成本,远高于省下 0.8 秒延迟带来的体验收益。反过来说,半决赛也提供了最有价值的高并发样本,观赛面板的读流量会在两小时内达到周内峰值,这正是切主之前最需要的一份数据。
十一、给做同类系统的人:先写下「不下沉什么」
第一天跑完,最值得复述的经验只有一条:先明确列出不能下沉的判定,再讨论下沉哪些。把跨全局的、需要全体数据的、涉及权限封禁的三类挑出来留在中心,剩下的才有讨论空间。
第二值得复述的是给每一段单独设预算并公开实测。910ms 对 900ms 的超支被写进报表,而不是等整体做完再宣布达标,这比任何优化技巧都更能保证结果可信。第三则是影子阶段的存在:任何一致性风险,都应该先在一份不影响任何人的数据上暴露一次。鼎上娱乐会持续跟进这两个节点在下一周的灰度表现。