第413章 800毫秒！
十二月了。
老周的第二版方案在十一月最後一天跑通了。
方遠用了一周時間重寫了餘額鏡像模塊的核心邏輯，把鏡像同步的頻率從每筆交易實時同步改成了批量異步同步，每500毫秒同步一次。
這樣做減少了單筆交易的等待時間，把延遲從最初的800多毫秒壓到了一個相對穩定的區間。
相對穩定的區間是多少呢。
老周在郵件里附了一張測試報告。
單筆交易延遲：平均793毫秒，最低612毫秒，最高1247毫秒。
793毫秒。
央行的性能指標要求是500毫秒以內。
Demo里跑出來的37毫秒是純邏輯層的數據，不含清算系統對接。
加上對接之後，延遲翻了二十多倍。
第二版比第一版好了一點，從」完全不能用」變成了」能用但不達標」。
差了將近300毫秒。
300毫秒聽起來不多，0.3秒，一眨眼的功夫。
但在冬奧的場景里，這0.3秒可能是災難性的。
冬奧期間數字人民幣的核心支付場景是什麼？
便利店、餐飲、紀念品商店、交通。
冬奧村的便利店在比賽日的尖峰時段，一個小時可能有幾百人排隊結帳。
每一筆支付如果多等0.3秒，幾百筆就是幾十秒到一兩分鐘的排隊延長。
運動員和記者不會等。
他們會掏出信用卡，或者打開手機用微信支付寶。
數字人民幣在冬奧的第一印象就是」慢」。
這不是技術問題。
這是政治問題。
冬奧是數字人民幣面向全球的第一次亮相，亮相的第一印象是」慢」，對整個DCEP項目的推廣是毀滅性的。
央行不會允許這種事發生。
更糟糕的是，趙銘遠的同步清算方案不存在這個問題。
同步架構的延遲完全取決於清算引擎本身的處理速度，工行的清算引擎經過了幾十年的優化，單筆交易確認時間在200毫秒以內。
如果央行看到的測試數據是微光610毫秒對工行200毫秒，結論不需要討論。
793毫秒，不達標，而且對手在達標。
…………
十二月第一周，老周的團隊開始了密集的優化疊代。
方向有三個。
第一個是壓縮鏡像同步的批量間隔，從500毫秒試著壓到300毫秒。
壓下去了，但延遲只降了40毫秒左右，從793降到了大約750。
第二個方向是優化回調通信的協議，減少每次回調的數據包大小和握手次數。
這個方向有效果，延遲又降了大概60毫秒，到了690左右。
第三個方向是方遠提出的，在邏輯層和清算系統之間加一個緩衝隊列，把回調請求排隊處理，減少並發衝突。
這個方向花了三天寫代碼，跑出來的結果是延遲降了30毫秒，代價是在高並發場景下緩衝隊列會堆積，堆積到一定程度延遲反而會飆升。
三個方向加起來，延遲從793降到了大約660。
還是超標，超了160毫秒。
…………
十二月第二周，又試了兩個方向。
一個是把邏輯層的規則引擎從解釋執行改成預編譯執行，把規則在第一次加載的時候就編譯成機器碼，後續執行的時候不再需要實時解析。
這個改動很大，方遠帶著兩個人花了五天重寫了規則編譯器。
跑出來的效果：延遲降了大約50毫秒，到了610左右。
另一個是老周自己想的，把清算系統的模擬環境從單機改成了分布式集群，更接近真實的央行架構。
改完之後重新跑測試，延遲反而上升了，因為分布式集群的網絡延遲比單機高。
這個結果說明之前的優化有一部分是建立在模擬環境不夠真實的基礎上的。
實際部署到真實環境裡，延遲可能比測試數據更高。
老周把這個結論寫在了白板上，紅色馬克筆，三個字：」不樂觀。」
…………
兩周過去了。
從十二月初到十二月中旬，十四天，七次測試疊代，延遲從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，壓不下去了。
他沒辦法。
老周的第二版方案在十一月最後一天跑通了。
方遠用了一周時間重寫了餘額鏡像模塊的核心邏輯，把鏡像同步的頻率從每筆交易實時同步改成了批量異步同步，每500毫秒同步一次。
這樣做減少了單筆交易的等待時間，把延遲從最初的800多毫秒壓到了一個相對穩定的區間。
相對穩定的區間是多少呢。
老周在郵件里附了一張測試報告。
單筆交易延遲：平均793毫秒，最低612毫秒，最高1247毫秒。
793毫秒。
央行的性能指標要求是500毫秒以內。
Demo里跑出來的37毫秒是純邏輯層的數據，不含清算系統對接。
加上對接之後，延遲翻了二十多倍。
第二版比第一版好了一點，從」完全不能用」變成了」能用但不達標」。
差了將近300毫秒。
300毫秒聽起來不多，0.3秒，一眨眼的功夫。
但在冬奧的場景里，這0.3秒可能是災難性的。
冬奧期間數字人民幣的核心支付場景是什麼？
便利店、餐飲、紀念品商店、交通。
冬奧村的便利店在比賽日的尖峰時段，一個小時可能有幾百人排隊結帳。
每一筆支付如果多等0.3秒，幾百筆就是幾十秒到一兩分鐘的排隊延長。
運動員和記者不會等。
他們會掏出信用卡，或者打開手機用微信支付寶。
數字人民幣在冬奧的第一印象就是」慢」。
這不是技術問題。
這是政治問題。
冬奧是數字人民幣面向全球的第一次亮相，亮相的第一印象是」慢」，對整個DCEP項目的推廣是毀滅性的。
央行不會允許這種事發生。
更糟糕的是，趙銘遠的同步清算方案不存在這個問題。
同步架構的延遲完全取決於清算引擎本身的處理速度，工行的清算引擎經過了幾十年的優化，單筆交易確認時間在200毫秒以內。
如果央行看到的測試數據是微光610毫秒對工行200毫秒，結論不需要討論。
793毫秒，不達標，而且對手在達標。
…………
十二月第一周，老周的團隊開始了密集的優化疊代。
方向有三個。
第一個是壓縮鏡像同步的批量間隔，從500毫秒試著壓到300毫秒。
壓下去了，但延遲只降了40毫秒左右，從793降到了大約750。
第二個方向是優化回調通信的協議，減少每次回調的數據包大小和握手次數。
這個方向有效果，延遲又降了大概60毫秒，到了690左右。
第三個方向是方遠提出的，在邏輯層和清算系統之間加一個緩衝隊列，把回調請求排隊處理，減少並發衝突。
這個方向花了三天寫代碼，跑出來的結果是延遲降了30毫秒，代價是在高並發場景下緩衝隊列會堆積，堆積到一定程度延遲反而會飆升。
三個方向加起來，延遲從793降到了大約660。
還是超標，超了160毫秒。
…………
十二月第二周，又試了兩個方向。
一個是把邏輯層的規則引擎從解釋執行改成預編譯執行，把規則在第一次加載的時候就編譯成機器碼，後續執行的時候不再需要實時解析。
這個改動很大，方遠帶著兩個人花了五天重寫了規則編譯器。
跑出來的效果：延遲降了大約50毫秒，到了610左右。
另一個是老周自己想的，把清算系統的模擬環境從單機改成了分布式集群，更接近真實的央行架構。
改完之後重新跑測試，延遲反而上升了，因為分布式集群的網絡延遲比單機高。
這個結果說明之前的優化有一部分是建立在模擬環境不夠真實的基礎上的。
實際部署到真實環境裡，延遲可能比測試數據更高。
老周把這個結論寫在了白板上，紅色馬克筆，三個字：」不樂觀。」
…………
兩周過去了。
從十二月初到十二月中旬，十四天，七次測試疊代，延遲從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，壓不下去了。
他沒辦法。