十二月了。



老周的第二版方案在十一月最后一天跑通了。



方远用了一周时间重写了余额镜像模块的核心逻辑，把镜像同步的频率从每笔交易实时同步改成了批量异步同步，每500毫秒同步一次。



这样做减少了单笔交易的等待时间，把延迟从最初的800多毫秒压到了一个相对稳定的区间。



相对稳定的区间是多少呢。



老周在邮件里附了一张测试报告。



单笔交易延迟：平均793毫秒，最低612毫秒，最高1247毫秒。



793毫秒。



央行的性能指标要求是500毫秒以内。



deo里跑出来的37毫秒是纯逻辑层的数据，不含清算系统对接。



加上对接之后，延迟翻了二十多倍。



第二版比第一版好了一点，从"完全不能用"变成了"能用但不达标"。



差了将近300毫秒。



300毫秒听起来不多，03秒，一眨眼的功夫。



但在冬奥的场景里，这03秒可能是灾难性的。



冬奥期间数字人民币的核心支付场景是什么？



便利店、餐饮、纪念品商店、交通。



冬奥村的便利店在比赛日的高峰时段，一个小时可能有几百人排队结账。



每一笔支付如果多等03秒，几百笔就是几十秒到一两分钟的排队延长。



运动员和记者不会等。



他们会掏出信用卡，或者打开手机用微信支付宝。



数字人民币在冬奥的第一印象就是"慢"。



这不是技术问题。



这是政治问题。



冬奥是数字人民币面向全球的第一次亮相，亮相的第一印象是"慢"，对整个dcep项目的推广是毁灭性的。



央行不会允许这种事发生。



更糟糕的是，赵铭远的同步清算方案不存在这个问题。



同步架构的延迟完全取决于清算引擎本身的处理速度，工行的清算引擎经过了几十年的优化，单笔交易确认时间在200毫秒以内。



如果央行看到的测试数据是微光610毫秒对工行200毫秒，结论不需要讨论。



793毫秒，不达标，而且对手在达标。



…………



十二月第一周，老周的团队开始了密集的优化迭代。



方向有三个。



第一个是压缩镜像同步的批量间隔，从500毫秒试着压到300毫秒。



压下去了，但延迟只降了40毫秒左右，从793降到了大约750。



第二个方向是优化回调通信的协议，减少每次回调的数据包大小和握手次数。



这个方向有效果，延迟又降了大概60毫秒，到了690左右。



第三个方向是方远提出的，在逻辑层和清算系统之间加一个缓冲队列，把回调请求排队处理，减少并发冲突。



这个方向花了三天写代码，跑出来的结果是延迟降了30毫秒，代价是在高并发场景下缓冲队列会堆积，堆积到一定程度延迟反而会飙升。



三个方向加起来，延迟从793降到了大约660。



还是超标，超了160毫秒。



…………



十二月第二周，又试了两个方向。



一个是把逻辑层的规则引擎从解释执行改成预编译执行，把规则在第一次加载的时候就编译成机器码，后续执行的时候不再需要实时解析。