一、11 月 5 日 00:00,赛事冻结期正式生效
从今天零点起到 11 月 7 日 24:00(季军赛与冠军赛全部结束),鼎上娱乐天工引擎进入"赛事冻结期"。冻结期只有一条铁律:边缘节点只观测、不切主。这是写死在准入预案里的纪律,不是临时决定。前几轮讲了准入关怎么设计、观察窗怎么连续达标,今天是这套机制第一次撞上真实大考。
二、并发峰值,恰好给"连续达标窗口"加压
半决赛带来的流量峰值,是检验"连续达标窗口"含金量的最好压力源。之前的达标是在平稳期测出来的,今天要在高并发、突增请求下继续站在 99.9% 之上——这才是它到底"真达标"还是"看着达标"的分水岭。冻结期的意义就在这:大考当天不改动主写逻辑,只用最严的并发去验证已有的结论。
三、观察日志今天怎么记:六栏位、30 秒一快照
赛事冻结期的数据,全靠一份结构统一的观察日志。竞技组和技术线约定的栏位固定六项。
- 时间戳(每 30 秒一条快照)
- 双写一致性(主库与影子库是否同步)
- 复制滞后(当前毫秒值)
- P95 延迟(读写尾延迟)
- 差异条数(两次写入结果不一致的条目)
- 是否逼近回退线
六栏位逐快照记录,不追求当天出结论,追求"原始数据一条不缺"。
四、为什么冻结期绝不切主
主写切换是全链路里最不可逆的动作之一:一旦切主,写入路由、缓存一致性与回退路径会同时改变。赛事期间并发高、容错低,任何一次切主若踩到边界问题,影响的就是成千上万条实时请求,且无法在赛中场内回滚。冻结期把"切主"这个决策权,整段让给赛后——比赛期间只做一件事:看清楚、记下来。
五、30 秒快照与正负 40 毫秒时钟偏移
多节点采集,最怕的不是数据难看,是数据不可信。各边缘节点之间存在约正负 40 毫秒的时钟偏移,如果按本地时间直接对齐,快照会出现错位。所以日志采用统一中心时间打点,以 30 秒为最小粒度聚合。首日数据尤其要确认时钟对齐无误——它是赛后整份评估的地基,地基歪了,后面全歪。
六、回退线 99.5%:今天会不会被逼近
准入方案里有一条明确的回退线:双写一致性连续 10 分钟跌破 99.5%,即触发回退评估。冻结期不切主,不代表不警戒——恰恰相反,峰值时段正是盯着这条线的时候。今天的任务不是触发回退,而是记录"峰值把一致性压到了什么位置、离回退线还有多少余量",为赛后的第一个切主评估攒证据。
七、首日记录的意义:给赛后第一个切主窗口打底
赛后什么时候才有第一个切主时机?要同时满足:达标窗口在真实并发下站住了、回退演练可达、日志里没有出现无法解释的差异条数。首日记录本身不下判断,但它决定了这个时机是"赛后第一天就能定",还是"还得再攒几天"。今天记得越干净,赛后的决策就越快。
八、明日预告:双倍夜加半决赛次日的双峰
提醒技术线同事,明天(11 月 6 日)是冻结期最紧的一天——白天是半决赛次日,晚上 20:00 到 22:00 又是周五双倍经验夜,两个并发高峰叠在一起。今天的快照框架和栏位要在今天就跑顺,别等到明天的双峰才开始调试记录方式。冻结期拼的不是胆量,是准备。