上一篇讲断档时留了一句"下一步是边缘节点同步",今天这条有了具体方案:把判定的本地快照从中心机房下沉到区域节点,目标是一次断流的最大影响面从5.2秒压到0.9秒以内。这一篇讲怎么做、分几步、哪些东西不下沉。
一、要解决的不是网络,是等待
结算夜那次5.2秒里,真正的问题不是链路断了5.2秒,而是系统在断流期间仍然在等中心返回确认。等的这5.2秒里,面板显示"待确认",判罚被排在队首但没落地。
网络抖动没法消,物理上就会抖。能改的是"等谁":如果区域节点自己就有一份可判定的状态,大部分情况下不必等中心。鼎上娱乐天工引擎这次下沉的动机就是这个,不是提速,是去掉一次跨地域等待。
二、0.9 秒怎么拆
三段预算:采集300毫秒、本地落库400毫秒、回传校验200毫秒。加起来正好800毫秒,留100毫秒给排队抖动。
这比揭幕夜数据链路那次1.5秒接力短了将近一半,当时耗时最大的一段就是回中心写库。把写库改到区域节点完成,是省出这700毫秒的唯一办法。
三、三个阶段:试点、双写、切主
第一阶段只在两个区域节点做试点,不参与判定,只把中心算完的结果复制到本地存一份,用来核对一致性。第二阶段双写,本地和中心同时写,以中心为准;第三阶段才让边缘做主判定,中心变成汇总与复核。
每个阶段都有回退条件:一致率低于99.5%就退回上一阶段,不带着问题往下走。这条写在方案第一页,也是我们内部先定死的规则。
四、哪些判定留在中心
三类不下沉:档位评定、结算发放、封禁判定。它们共同的特征是"错了影响很长",一次错误要好几周才暴露,而且没法靠补发修好。
下沉的是短时判定:点位归属、读条是否被打断、单次提交是否到达。这些错了,影响范围就是那一次动作,补得回来。断档那篇里的降级顺序在这里同样成立:先保结果层,再保显示层。
五、双写期最容易出现的问题
两边都写,就会有不一致。规则仍是"以带原始标记的一方为准",补算的一方进待核清单,人工复核窗口24小时。
双写期新增了一条约束:边缘写的那一份必须带上写入时刻的区域时钟偏移量。之前只有中心记录时间,下沉之后如果不知道节点本地钟差多少,两笔几乎同时的写入就没法排序。这类问题不是设计出来的,是跑出来的。
六、试点节点的三条标准
第一,公网P95延迟低于35毫秒;第二,过去90天节点可用率高于99.9%;第三,覆盖的活跃玩家数量要足够大到能跑出样本,又不能大到一次故障影响一片。
三条里最难同时满足的是第三条。延迟低、可用率高的节点往往在一线城市,玩家集中,一次事故就是全国性的;所以这次选了两个二线节点,延迟略高但影响面可控。
七、灰度顺序
先放观赛面板——它错了没人申诉,只是数字难看;再放实时点位归属;最后才放判罚。这个顺序和重要性无关,和"错了之后能不能悄悄修"有关。
赛事侧的灰度会更保守:半决赛期间(11月5、6日)只观测不切主,判罚仍走中心链路。面板数据可以下沉显示,结果不行。
八、玩家会先看到什么变化
第一个可感知的变化是"待确认"标记变少。它出现的频率取决于断流持续时间,快照下沉后,大部分2秒内的抖动都能在本地完成判定,不再需要挂起等待。
第二个变化在回放里。补算区间的灰段会缩短,长灰段基本只出现在真正的区域级故障时。数据链路首秀复盘里提到的那种1.5秒接力,在试点日志里现在普遍落在0.6到0.8秒。
九、写在最后
时间表:第一阶段本周开始,第二阶段预计11月中旬,第三阶段要等赛事结束以后。0.9秒是设计目标,不是承诺值——它会随网络条件波动,断档不会消失。
能承诺的是另外两件事:任何一次补算都会留标记,任何一次下沉都不会碰档位与结算。至于试点期间要不要在结算夜避开高并发窗口,可以对照次周路线那篇的时间表自己看——本周五那天,我们同样会把切主动作往后挪一天。