2月14日。



冰壶决赛日。



…………



晚上八点。



监控室里坐了三个人，老周在1号位，方远在3号位，5号工位的值班员在记录。



大屏幕上的交易数据在爬升，冰壶决赛的关注度比前几天的比赛高，场馆消费在增加，每秒处理笔数从下午的15左右爬到了35，然后40。



正常的比赛日曲线，涨。



老周看了一眼，端起搪瓷缸，铁观音，第二泡。



方远在盯竞态检测日志，习惯了，十天了，每天盯，绿，永远的绿，他有时候觉得这些绿色的字符已经刻进了视网膜里，闭上眼睛都能看到。



…………



八点十七分。



数字在爬。



45，50，55。



比赛进行到了一个关键时刻，解说员大概在喊什么，场馆里的气氛大概很热，他们不知道，他们只看数字。



58，62。



正常。



65，68。



方远的眼睛跟着数字走，日志在刷，绿，绿，绿。



70，73。



跟短道速滑决赛日的峰值一样了。



75。



超了。



方远坐直了。



78，80。



老周放下了搪瓷缸。



82。



还在爬。



…………



八点十八分。



方远的屏幕上，竞态检测日志刷出了一行新的记录。



不是绿色的。



黄色的。



"race_check: tercept tistap: 20:18:03714 trigger: ncurrent_lock_ntention resotion: pre-eptive_rollback tency: 03s"



方远的手停了。



他盯着这行字，眼睛没有眨，屏幕上的光直接照进他的瞳孔里，黄色的字符在黑色的终端背景上非常显眼，从切流到现在十一天，这是第一行不是绿色的记录。



黄色，不是红色，黄色是"拦截成功"，红色是"拦截失败"。



拦截成功。



竞态修复补丁被触发了，在真实环境里，不是模拟，不是测试，是真的。



在并发量达到82的时候，两个交易请求同时访问了同一个账本锁，竞态条件出现了，在老版本里，这会导致一个短暂的数据不一致，可能是05秒的延迟，可能是一笔交易的状态错误，在测试环境里不算什么，在全球直播的冬奥运行环境里，这是事故。



但补丁拦截了它。



在竞态条件实际发生前03秒，补丁检测到了锁竞争的前兆信号，主动回滚了其中一个请求，让它重新排队，03秒后那个请求重新执行，成功，零错误，零延迟，用户端无感知。



03秒。



方远盯着屏幕。



他的手指搭在键盘边沿，指关节发白，不是用力，是绷着。



…………



大屏幕上的数字在回落。



80，75，70，65。



比赛的关键时刻过去了，消费高峰回落。



方远没有动。



他在看日志。