第413章 800毫秒！（2/2）

请关闭浏览器的阅读/畅读/小说模式并且关闭广告屏蔽过滤功能，避免出现内容无法显示或者段落错乱。

实际部署到真实环境里，延迟可能比测试数据更高。

老周把这个结论写在了白板上，红色马克笔，三个字：“不乐观。“

…………

两周过去了。

从十二月初到十二月中旬，十四天，七次测试叠代，延迟从793毫秒降到了610毫秒。

降了183毫秒，但还是超標110毫秒。

而且这110毫秒不是“再优化优化就能压下去“的那种差距。

方远在最后一次测试之后做了一个分析，把延迟拆成了五个环节：规则编译18毫秒，规则执行22毫秒，镜像同步310毫秒，回调通信195毫秒，清算確认65毫秒。

五个环节加起来610毫秒。

每个环节的优化都已经接近各自的理论极限了，规则执行从37毫秒压到22毫秒已经是三次重写的结果，回调通信从280毫秒压到195毫秒是协议层面的极限。

瓶颈在镜像同步，310毫秒，占了总延迟的一半以上。

镜像同步的310毫秒是余额镜像方案的先天代价。

要维护一份本地的余额副本，就必须定期跟清算系统的真实帐本同步。

同步频率越高，镜像越准，但延迟越大。

同步频率越低，延迟越小，但双花风险越高。

这是一个蹺蹺板，两头不能同时落地。

老周在最新的邮件里说，现有架构下的优化空间已经接近极限。

余额镜像方案的核心逻辑决定了延迟的下限，不改架构就压不下去。

不改架构。

改架构意味著推倒重来。

第二版方案跑了两周，方远重写了规则编译器，老周重搭了模擬集群，十二个人每天干十四五个小时。

这些工作如果全部作废，从零开始，时间不够了。

离冬奥实战测试还有不到一个月。

…………

林彻看完了老周的邮件。

十二月十五號的晚上，七楼办公室。

窗外的杭州在下雨，不是大雨，是那种密密的细雨，看不清雨丝但能听到雨打在窗户上的声音，沙沙的，连成一片。

路灯的光被雨雾打散了，变成一团一团的晕。

对面楼的灯灭了大半，只有零星几间还亮著，加班的人或者忘了关灯。

桌上的茶凉了，他没喝。

610毫秒。

白板上那五个时间节点，11月15日的架构设计完成了，11月30日的核心引擎原型跑通了，但跑通不等於达標。

12月15日是今天，规则编译器对接完成了，延迟没有压到500以內。

下一个节点是12月31日，全链路测试通过。

还有十六天。

十六天里要做的事：要么把现有架构的延迟从610压到500以內，要么找到一个全新的架构思路。

前者老周说已经穷尽了。

后者意味著在十六天內完成从设计到开发到测试的全流程。

老周的邮件最后没有写“在想办法“或者“还在优化“。

他写的是一句话：

“现有架构下的优化空间已经穷尽。需要新的思路。“

需要新的思路。

这句话从老周嘴里说出来，比从任何人嘴里说出来都重。

老周不是会轻易认输的人。

他说穷尽了就是真的穷尽了，他说需要新思路就是现有的路真的走不通了。

窗外的雨还在下。

沙沙的声音不断，像白噪音，填满了整间办公室。

800毫秒，压到了610，压不下去了。

他没办法。