2月23日晚上九點(diǎn)多我正盯著比賽后臺(tái)的行情面板群里突然彈出一條監(jiān)控告警主行情鏈路延遲超過400毫秒。平時(shí)這個(gè)數(shù)字穩(wěn)定在20到30毫秒那一刻我第一反應(yīng)是“網(wǎng)絡(luò)抽風(fēng)了吧”但緊接著第二條告警跟著來了消息積壓隊(duì)列長(zhǎng)度突破一萬(wàn)然后第三條、第四條……那天晚上全網(wǎng)有13萬(wàn)人爆倉(cāng)我們這套參賽用的小數(shù)據(jù)系統(tǒng)硬生生扛住了整場(chǎng)風(fēng)暴。先交代下背景。我們小組參加的是那個(gè)面向加密量化團(tuán)隊(duì)的聯(lián)賽組隊(duì)三個(gè)月系統(tǒng)從采集層到策略層全是我們自己攢的。量化和傳統(tǒng)軟件開發(fā)有個(gè)特別不一樣的地方你寫的每一行代碼都在跟真金白銀和市場(chǎng)波動(dòng)打交道出了事沒有“回滾”這個(gè)按鈕因?yàn)樾星椴粫?huì)等你。所以那晚之后我一直在想為什么我們的系統(tǒng)能在這么大的壓力下沒倒運(yùn)氣占多少設(shè)計(jì)占多少?gòu)?fù)盤完最大的感受是所謂扛住了根本不是什么幸運(yùn)而是前面那些不起眼的防御性設(shè)計(jì)在關(guān)鍵時(shí)候一個(gè)個(gè)接住了子彈。1. 那個(gè)21點(diǎn)09分的警報(bào)行情引擎第一次亮紅燈那天晚上的行情現(xiàn)在回想依然覺得夸張。主流的幾個(gè)大幣種幾分鐘內(nèi)跌掉十幾個(gè)百分點(diǎn)山寨幣更不用說訂單簿上原來疊得整整齊齊的買盤賣盤像被抽掉地基一樣嘩啦啦塌掉。全網(wǎng)強(qiáng)制平倉(cāng)人數(shù)達(dá)到13萬(wàn)這意味著無(wú)數(shù)止損單、強(qiáng)平單在同一時(shí)間涌進(jìn)交易所的撮合系統(tǒng)市場(chǎng)流動(dòng)性瞬間被抽干。我們監(jiān)控面板上多個(gè)交易對(duì)的買賣價(jià)差從正常的0.1%一路拉到0.8%甚至更高盤口五檔價(jià)格像壞掉的電梯上上下下亂跳。如果是普通的行情軟件頂多是畫面卡頓、指標(biāo)失真。但對(duì)我們參加量化賽的一組選手來說行情數(shù)據(jù)是策略的糧食誰(shuí)先把干凈的糧食送到算法嘴邊誰(shuí)就能躲過這輪絞肉機(jī)。1.1 一晚上13萬(wàn)人爆倉(cāng)究竟意味著什么先說清楚“13萬(wàn)人爆倉(cāng)”這個(gè)數(shù)字背后的數(shù)據(jù)壓力。爆倉(cāng)潮最直接的表現(xiàn)是交易所的委托流和成交流瞬間放大數(shù)倍。我們訂閱了大約40個(gè)高流動(dòng)性交易對(duì)平時(shí)每條WebSocket鏈路每秒推送幾百條增量消息那天晚上直接沖破幾千條全局消息速率峰值大概是正常時(shí)段的10倍上下。聽起來10倍不算恐怖但行情消息有個(gè)特點(diǎn)單條體積小、頻率超高而且對(duì)順序極度敏感。10倍流量意味著事件隊(duì)列、序列化解析、內(nèi)存分配全部進(jìn)入高壓狀態(tài)任何一個(gè)環(huán)節(jié)出現(xiàn)瓶頸都會(huì)讓延遲從毫秒級(jí)惡化到秒級(jí)。更麻煩的是爆倉(cāng)強(qiáng)平的委托五花八門。有些是市價(jià)單直接吃掉整個(gè)盤口有些是限價(jià)單掛在明顯離譜的位置還有些成交回報(bào)里夾雜著部分成交、撤銷、被拒等狀態(tài)。訂單簿處理管線一旦遇到這些異常情況如果沒有嚴(yán)格的校驗(yàn)邏輯內(nèi)部狀態(tài)就會(huì)悄悄偏離真實(shí)行情。當(dāng)盤口深度本身就在劇烈變化時(shí)這種偏離幾乎是不可逆的——你手里的訂單簿看起來還在更新實(shí)際上已經(jīng)是一個(gè)“平行宇宙”策略基于它算出來的信號(hào)自然全是垃圾。1.2 爆倉(cāng)潮為什么是數(shù)據(jù)系統(tǒng)的壓力放大器把爆倉(cāng)潮單純理解為“行情變快”是不對(duì)的。我覺得它真實(shí)考驗(yàn)的是三個(gè)維度吞吐量、順序一致性、以及故障自愈能力。吞吐量考驗(yàn)的是系統(tǒng)能不能消費(fèi)掉瞬間涌入的行情消息。我們?cè)谠O(shè)計(jì)時(shí)估算過單條大幣種增量消息約200字節(jié)40個(gè)交易對(duì)峰值做到每秒5萬(wàn)條消息理論上要保證幾十兆每秒的解析能力。這個(gè)量級(jí)日常完全夠用可一旦遇到強(qiáng)平潮若消息處理線程池不夠隊(duì)列就會(huì)積壓內(nèi)存占用持續(xù)上漲最終觸發(fā)GC停頓或OOM。順序一致性則是更隱蔽的坑。行情增量消息自帶序列號(hào)我們的行情網(wǎng)關(guān)每次收到一批消息后都會(huì)檢查序列號(hào)是否連續(xù)。如果中間跳躍了說明丟包了必須觸發(fā)全量快照對(duì)賬而不是悶頭繼續(xù)處理。那天晚上就出現(xiàn)過一次序列號(hào)跳躍好在對(duì)賬機(jī)制自動(dòng)介入沒有讓臟數(shù)據(jù)流到下游。“自愈”則體現(xiàn)在網(wǎng)絡(luò)斷線、服務(wù)重啟這些故障場(chǎng)景中。很多系統(tǒng)平時(shí)跑得歡一遇到斷線重連就開始丟狀態(tài)重連完成后訂單簿還要花好幾秒重新構(gòu)建而這期間策略相當(dāng)于瞎了。我們預(yù)設(shè)了一套重連策略斷線后先拉全量快照再回放斷線期間積壓的增量重建完成前直接攔掉策略信號(hào)。不要小看這個(gè)操作它保證了輸出的信號(hào)要么準(zhǔn)確要么沒有絕不會(huì)給策略一個(gè)模棱兩可的中間態(tài)。2. 賽前系統(tǒng)設(shè)計(jì)一切為“降延遲”但更為了“不臟數(shù)據(jù)”很多做量化的朋友一上來就追求極致延遲恨不得把行情網(wǎng)關(guān)跟策略進(jìn)程綁在同一個(gè)CPU核心里。我們一開始也走過這條路但很快發(fā)現(xiàn)對(duì)大部分中頻選幣策略來說20毫秒和50毫秒的差別根本不影響盈虧真正影響盈虧的是數(shù)據(jù)錯(cuò)了。一套行情系統(tǒng)最重要的指標(biāo)不是“快”而是“可靠”。2.1 行情接入層全量增量雙通道為什么必須兩手都要抓我們的行情接入分兩條路一條是WebSocket推送通道負(fù)責(zé)實(shí)時(shí)增量一條是REST快照接口每隔2秒拉一次全量盤口用于對(duì)賬。這是業(yè)內(nèi)比較成熟的實(shí)踐做起來卻有不少細(xì)節(jié)。一開始我們也考慮過只依賴WebSocket增量推送覺得省事。但增量鏈路在長(zhǎng)期運(yùn)行下幾乎必然會(huì)丟消息網(wǎng)絡(luò)抖動(dòng)、服務(wù)端重啟、本地處理不及時(shí)原因太多了。一旦丟了一條訂單簿里某個(gè)價(jià)格檔位的數(shù)量就會(huì)永遠(yuǎn)對(duì)不上之后所有基于這個(gè)訂單簿計(jì)算的指標(biāo)都會(huì)帶偏差。最可怕的是這個(gè)偏差不會(huì)自動(dòng)修復(fù)它會(huì)在你看不見的地方慢慢侵蝕策略信號(hào)。所以我們強(qiáng)制每2秒做一次全量對(duì)賬把本地訂單簿和交易所快照進(jìn)行哈希比對(duì)一旦不一致立刻觸發(fā)重同步。對(duì)賬機(jī)制的實(shí)現(xiàn)也有講究。不能在一個(gè)線程里既處理增量又處理快照否則順序就亂了。我們用序列號(hào)做關(guān)卡快照消息只有在它的序列號(hào)大于當(dāng)前已處理序列號(hào)時(shí)才會(huì)被接受并重置本地訂單簿否則直接丟棄。這個(gè)邏輯聽起來簡(jiǎn)單但在高并發(fā)、多交易對(duì)并行時(shí)要仔細(xì)處理鎖競(jìng)爭(zhēng)我們用了一個(gè)全局槽位鎖的變體設(shè)計(jì)讓每個(gè)交易對(duì)獨(dú)立比較互相不拖累。增量消息的解析我們也沒有用現(xiàn)成的JSON解析器直接全套上陣。JSON在常規(guī)場(chǎng)景下沒問題但極端行情下字符串解析和對(duì)象創(chuàng)建帶來的CPU開銷和內(nèi)存碎片會(huì)被放大。比較穩(wěn)妥的做法是使用帶緩沖的二進(jìn)制解析器提前分配好對(duì)象池不做無(wú)謂的內(nèi)存申請(qǐng)。這可能讓你少寫不少“看上去很爽”的靈活代碼但換來的穩(wěn)定性非常值。2.2 計(jì)算與風(fēng)控層寧可慢20毫秒不做裸算行情網(wǎng)關(guān)解包之后數(shù)據(jù)去哪里我們的答案是絕不直接在網(wǎng)關(guān)線程里算指標(biāo)所有計(jì)算邏輯都放到獨(dú)立線程池。這樣做的原因有兩個(gè)安全與隔離。行情網(wǎng)關(guān)如果被計(jì)算邏輯拖住積壓?jiǎn)栴}會(huì)迅速上拋?zhàn)詈笳麄€(gè)鏈路雪崩而獨(dú)立線程池則意味著計(jì)算慢一點(diǎn)無(wú)所謂不會(huì)反過來阻塞消息接收。在這個(gè)線程池里我們實(shí)時(shí)維護(hù)每個(gè)交易對(duì)的狀態(tài)并計(jì)算幾個(gè)核心指標(biāo)。這里必須提一個(gè)關(guān)鍵詞置信度。市場(chǎng)劇烈波動(dòng)時(shí)任何指標(biāo)都可能產(chǎn)生尖峰比如訂單簿深度不足時(shí)算出來的“加權(quán)買賣壓力”其實(shí)毫無(wú)意義。我們給每個(gè)指標(biāo)附加了一個(gè)質(zhì)量標(biāo)簽如果當(dāng)時(shí)盤口深度低于某個(gè)閾值或者價(jià)差超過歷史分布的P99.5分位該指標(biāo)會(huì)被標(biāo)記為“不可用”策略端拿不到任何新信號(hào)。寧可不出信號(hào)不可出假信號(hào)。這句話在后來的復(fù)盤中被反復(fù)提到。很多系統(tǒng)不是被行情打死而是被一個(gè)冒似正常、實(shí)際已經(jīng)失真的信號(hào)害死。置信度機(jī)制就是把這層保護(hù)焊死。2.3 持久化與事后復(fù)盤行情數(shù)據(jù)怎么留下可追溯的證據(jù)比賽那晚整個(gè)系統(tǒng)每秒都在產(chǎn)生海量行情消息如果不做存儲(chǔ)事后復(fù)盤就只能靠記憶和猜測(cè)。我們的方案比較樸素MySQL存業(yè)務(wù)狀態(tài)ClickHouse存行情明細(xì)。ClickHouse的列式存儲(chǔ)和批量寫入特性讓它在高頻append場(chǎng)景下表現(xiàn)得非常從容。每天晚上我們還會(huì)額外把當(dāng)天每個(gè)交易對(duì)的訂單簿快照鏈壓縮存檔。這個(gè)過程看似浪費(fèi)存儲(chǔ)卻是復(fù)盤最有力的武器——當(dāng)你想知道“那一刻到底發(fā)生什么”只有快照能告訴你。沒有它所有的復(fù)盤都會(huì)變成“我覺得當(dāng)時(shí)盤口怎樣怎樣”。當(dāng)然剛上線時(shí)我們犯過一個(gè)錯(cuò)誤為了省磁盤把增量日志直接丟棄只保留分鐘級(jí)聚合數(shù)據(jù)。后來一次普通的策略回測(cè)中我們發(fā)現(xiàn)指標(biāo)出現(xiàn)異常卻沒有任何底層數(shù)據(jù)能追溯到根因只能推倒重來。那次之后我們就學(xué)乖了紅盤數(shù)據(jù)可以丟原始行情絕不能隨便丟。3. 當(dāng)晚的防御動(dòng)作熔斷、降級(jí)與手動(dòng)干預(yù)的邊界預(yù)警機(jī)制的作用不是讓系統(tǒng)自動(dòng)解決一切問題而是在第一時(shí)間告訴值班員“出事了決策時(shí)間開始倒計(jì)時(shí)”。那天晚上我們的防御體系大概分成了三層監(jiān)控告警、自動(dòng)切換、手動(dòng)決策。每一層都有明確的動(dòng)作邊界這些邊界不是現(xiàn)場(chǎng)拍腦袋定的而是賽前演練里一遍遍錘出來的。3.1 警報(bào)閾值不是靠拍腦袋定的監(jiān)控閾值設(shè)太靈敏天天狼來了值班員會(huì)麻木設(shè)太遲鈍警報(bào)來了可能已經(jīng)晚了。我們最終采用了一套三級(jí)閾值每一級(jí)對(duì)應(yīng)不同的響應(yīng)動(dòng)作。等級(jí)觸發(fā)條件響應(yīng)動(dòng)作觀察級(jí)主鏈路延遲超過100ms或消息速率超過均值2倍推送工作群觀察1分鐘警告級(jí)延遲超過300ms且持續(xù)3秒或消息吞吐超過均值5倍技術(shù)值班員立即確認(rèn)數(shù)據(jù)是否新鮮關(guān)閉非核心模塊危急級(jí)延遲超過500ms或訂單簿重建連續(xù)失敗3次隊(duì)長(zhǎng)拍板切換備用行情源策略信號(hào)強(qiáng)制掛起這里有個(gè)數(shù)據(jù)要知道延遲閾值不是從文檔里抄的而是用監(jiān)控歷史回放分析得出的。我們把過去一個(gè)月的網(wǎng)絡(luò)延遲分布調(diào)出來找到P95和P99分位數(shù)再疊加上“如果是真正災(zāi)難行情”的估計(jì)值最終設(shè)定出100ms、300ms、500ms三檔。這樣能保證平時(shí)不會(huì)誤報(bào)真到關(guān)鍵時(shí)刻又不會(huì)漏報(bào)。3.2 應(yīng)對(duì)決策鏈誰(shuí)有權(quán)力切備用鏈路自動(dòng)切換和手動(dòng)干預(yù)兩者之間有嚴(yán)格的邊界。我們只對(duì)“無(wú)狀態(tài)故障”做全自動(dòng)切換比如主行情鏈路連接中斷、協(xié)議握手失敗這類問題特點(diǎn)就是狀態(tài)干凈切過去再補(bǔ)個(gè)快照就行。但“連接還在延遲異常數(shù)據(jù)疑似亂序”這種有狀態(tài)故障絕不能自動(dòng)切因?yàn)榍袚Q過程本身可能會(huì)引入重復(fù)或亂序的數(shù)據(jù)讓下游更加混亂。那天晚上主鏈路先是延遲升高隨后數(shù)據(jù)新鮮度開始波動(dòng)。我們等了幾秒確認(rèn)不是瞬時(shí)抖動(dòng)后隊(duì)長(zhǎng)拍板切到備用行情源整個(gè)過程大概花了6秒。這6秒如果發(fā)生在平時(shí)策略會(huì)短暫沒有新信號(hào)但不會(huì)犯錯(cuò)誤。放在那種瀑布行情里暫停6秒遠(yuǎn)遠(yuǎn)好過拿著舊數(shù)據(jù)硬算。為了不讓值班三人組同時(shí)改配置文件我們預(yù)約了明確的“單一決策人”機(jī)制。切源之前隊(duì)長(zhǎng)在語(yǔ)音里說一句“我準(zhǔn)備切了”其他人只負(fù)責(zé)確認(rèn)監(jiān)控面板不允許同時(shí)操作。聽起來像軍事化管理但極端行情下最怕的就是幾個(gè)人手忙腳亂誰(shuí)都覺得該做點(diǎn)事結(jié)果越搞越亂。3.3 那晚我們做對(duì)了的幾次關(guān)鍵降級(jí)降級(jí)不等于擺爛而是把資源投向最要緊的地方。那晚我們一共做了四次主動(dòng)降級(jí)每一次都是提前寫進(jìn)預(yù)案里的。第一次直接關(guān)掉了資金費(fèi)率套利、歷史波動(dòng)回放、費(fèi)率和資金費(fèi)率監(jiān)控等非核心模塊。這些模塊平時(shí)也在吃CPU和內(nèi)存但在生死關(guān)頭它們完全可以延期執(zhí)行。我們把進(jìn)程優(yōu)先級(jí)調(diào)高給核心信號(hào)計(jì)算讓路。第二次對(duì)行情源設(shè)置了“冷靜期”。如果某個(gè)交易所連續(xù)三次心跳超時(shí)就強(qiáng)制斷開連接等待60秒再嘗試重連。這個(gè)設(shè)計(jì)是為了防止臟數(shù)據(jù)無(wú)休止地重連、斷開、再重連——每重連一次都是災(zāi)難性的狀態(tài)重置。你那幾條數(shù)據(jù)鏈路看著還活著其實(shí)已經(jīng)死了這時(shí)候必須等真正的冷卻期走完。第三次手動(dòng)把回測(cè)數(shù)據(jù)庫(kù)的寫入暫停。我們預(yù)留了一臺(tái)獨(dú)立的回放服務(wù)器日常會(huì)把實(shí)時(shí)行情同步給它方便隨時(shí)回放和實(shí)驗(yàn)。但當(dāng)天晚上我們臨時(shí)把它降級(jí)為只接收暫不寫入給主進(jìn)程的磁盤IO讓路。這個(gè)操作省出來不少資源也避免了磁盤繁忙導(dǎo)致主線程卡頓。第四次也是最重要的一次對(duì)策略端實(shí)施“信號(hào)掛起”不讓它開新倉(cāng)。比賽里的倉(cāng)位是虛擬的但我們依然按照實(shí)戰(zhàn)標(biāo)準(zhǔn)來處理寧可錯(cuò)過后面的反彈也不在數(shù)據(jù)不確定時(shí)冒險(xiǎn)開單。事后證明這個(gè)選擇幫我們躲開了當(dāng)晚至少兩波假信號(hào)。4. 復(fù)盤清單扛住那晚的三個(gè)關(guān)鍵選擇與兩個(gè)未爆的雷比賽結(jié)束后我們把整個(gè)流程復(fù)盤了一遍認(rèn)真梳理了哪些設(shè)計(jì)在關(guān)鍵時(shí)候立了功哪些隱患雖然沒爆卻值得警惕。4.1 關(guān)鍵選擇一用獨(dú)立的行情網(wǎng)關(guān)進(jìn)程隔離故障我們當(dāng)時(shí)把行情接入、數(shù)據(jù)處理、策略決策拆成了三個(gè)獨(dú)立進(jìn)程用消息隊(duì)列連接。這讓運(yùn)維變得麻煩一點(diǎn)但換取的是故障隔離——即使行情網(wǎng)關(guān)因?yàn)樯嫌螖?shù)據(jù)異常耗盡內(nèi)存也只會(huì)導(dǎo)致網(wǎng)關(guān)自己崩潰重啟數(shù)據(jù)庫(kù)和策略進(jìn)程不受影響。比賽期間真的發(fā)生過一次由于上游推送異常導(dǎo)致的網(wǎng)關(guān)OOM主交易進(jìn)程完全沒受影響系統(tǒng)自動(dòng)重啟了網(wǎng)關(guān)幾秒后恢復(fù)正常運(yùn)行。如果你做不到進(jìn)程級(jí)隔離至少也要做到線程池隔離。最忌諱的就是把所有邏輯塞進(jìn)一個(gè)進(jìn)程里的同一組線程那樣一個(gè)模塊出事整個(gè)系統(tǒng)陪葬。4.2 關(guān)鍵選擇二消息格式里的序列號(hào)缺口檢測(cè)這條可能是全場(chǎng)最有價(jià)值的一行代碼。我們的每條行情增量消息都自帶單調(diào)遞增的序列號(hào)行情網(wǎng)關(guān)收到后第一件事不是解析內(nèi)容而是檢查序列號(hào)是否連續(xù)。一旦發(fā)現(xiàn)跳躍超過1說明中間丟了消息立刻觸發(fā)全量重同步而不是繼續(xù)拿著殘缺數(shù)據(jù)算下去。這里有個(gè)常見誤區(qū)看到序列號(hào)不連續(xù)就想當(dāng)然地去“補(bǔ)數(shù)”。其實(shí)補(bǔ)數(shù)往往補(bǔ)錯(cuò)因?yàn)槟悴恢纴G失區(qū)間里到底發(fā)生了什么盲猜出來的盤口狀態(tài)比不更新更危險(xiǎn)。正確做法永遠(yuǎn)是重置拉快照重新開始。當(dāng)然我們也遇到過交易所的序列號(hào)在服務(wù)端重啟后清零的情況。這種時(shí)候不能靠序列號(hào)判斷必須對(duì)照快照時(shí)間戳和業(yè)務(wù)id做二次校驗(yàn)。這些都是踩過坑才明白的。4.3 關(guān)鍵選擇三比賽前的“混亂演習(xí)”賽前兩周我們做過一次模擬極端行情的災(zāi)難演練。當(dāng)時(shí)直接把消息推送速度調(diào)到平時(shí)的15倍同時(shí)砍掉部分盤口深度還模擬了強(qiáng)制平倉(cāng)事件流。第一次演練的結(jié)果慘不忍睹系統(tǒng)在5分鐘內(nèi)內(nèi)存飆到90%訂單簿重建一直失敗監(jiān)控面板上一片紅。之后我們連夜定位根因修了三個(gè)明顯的瓶頸一是哈希表擴(kuò)容時(shí)造成全線程停頓換成了預(yù)分配大表方案二是磁盤日志寫得太頻繁CPU大量耗在系統(tǒng)調(diào)用上改成異步日志批量刷盤三是事件隊(duì)列無(wú)界導(dǎo)致內(nèi)存上漲換成了有界隊(duì)列加上背壓策略。第二次演練就順暢多了。如果賽前沒有做過這種“往死里打”的演習(xí)2月23日那天我們的結(jié)局大概率不是“扛住”兩個(gè)字而是“系統(tǒng)集體崩潰后在群里發(fā)通告”。演習(xí)不是走形式它是唯一能讓你在真實(shí)風(fēng)暴來臨前發(fā)現(xiàn)薄弱環(huán)節(jié)的機(jī)會(huì)。4.4 未爆的雷下一次可能擊中我們的暗礁復(fù)盤不能只看功勞簿還得看看哪些雷沒爆只是運(yùn)氣好。我們梳理出兩個(gè)至今沒有完美解決的點(diǎn)。第一個(gè)是單點(diǎn)依賴。雖然我們準(zhǔn)備了備用行情源但兩個(gè)行情源都來自同一家服務(wù)商只是網(wǎng)絡(luò)入口不同。萬(wàn)一服務(wù)商整體故障我們的雙路備份就形同虛設(shè)。后面考慮接入第三方獨(dú)立行情源做交叉校驗(yàn)但成本、延遲和維護(hù)復(fù)雜度都得重新權(quán)衡目前還沒落地。第二個(gè)是進(jìn)程重啟恢復(fù)時(shí)間太長(zhǎng)。如果承載訂單簿的進(jìn)程掛了恢復(fù)時(shí)必須先拉快照再回放增量實(shí)測(cè)大概需要90秒。在指數(shù)級(jí)別波動(dòng)的幾十秒里這個(gè)恢復(fù)時(shí)間簡(jiǎn)直是一個(gè)世紀(jì)。下一步想給進(jìn)程設(shè)計(jì)一個(gè)“只讀模式”允許它在恢復(fù)期間先以輕量方式觀察行情、暫不發(fā)單同時(shí)把恢復(fù)過程做成更細(xì)粒度的斷點(diǎn)續(xù)傳期望把恢復(fù)時(shí)間壓縮到10秒以內(nèi)。這兩個(gè)雷這次沒炸不代表下次不炸但至少我們已經(jīng)知道它們埋在哪里了。5. 如果你也想組一套抗極端行情的行情系統(tǒng)這些建議請(qǐng)收好很多朋友賽后問我你們這套系統(tǒng)能不能直接抄抄是可以抄但比抄更重要的是把設(shè)計(jì)背后的思路變成自己的。結(jié)合這次參賽經(jīng)驗(yàn)我整理了幾條可能幫助你少走彎路的建議。5.1 用“爆倉(cāng)事件”反推需求清單不要一上來就悶頭寫代碼。先坐下來把你最害怕的九個(gè)場(chǎng)景列出來。比如行情源突然斷開10秒怎么辦訂單簿錯(cuò)亂卻還沒被發(fā)現(xiàn)怎么辦核心進(jìn)程崩潰后恢復(fù)要多久連續(xù)三筆信號(hào)抖動(dòng)怎么辦值班的人手不夠怎么辦把這些場(chǎng)景一條條寫清楚系統(tǒng)設(shè)計(jì)自然就有了優(yōu)先級(jí)。我們當(dāng)初的需求表里“數(shù)據(jù)新鮮度檢查”排在“極致低延遲”前面“故障自動(dòng)恢復(fù)”排在“更多技術(shù)?！鼻懊?。這就是爆倉(cāng)事件反推出來的結(jié)果你最怕的事就是系統(tǒng)最需要防御的環(huán)節(jié)。5.2 日常備災(zāi)演練不能只在出事當(dāng)天才祈禱強(qiáng)烈建議每?jī)芍茏鲆淮伟胩焱暾膲毫胤叛萘?xí)。不是嘴上說“應(yīng)該沒問題”而是真的用歷史極端行情數(shù)據(jù)回放一遍全鏈路。演習(xí)時(shí)除了看技術(shù)指標(biāo)也要看人的決策速度。假設(shè)警報(bào)響了你不知道先看哪個(gè)面板或者預(yù)案里“重新同步訂單簿”這一步?jīng)]來得及執(zhí)行那下次真出事的時(shí)候你大概率會(huì)重復(fù)同樣的錯(cuò)誤。我們每次演習(xí)后都會(huì)輸出一份簡(jiǎn)短清單哪些環(huán)節(jié)順手哪些環(huán)節(jié)卡頓然后下輪迭代優(yōu)化。這個(gè)“演習(xí)—復(fù)盤—修正”的循環(huán)才是系統(tǒng)逐漸變硬的根本原因。5.3 少走彎路的幾個(gè)小細(xì)節(jié)最后分享幾個(gè)看起來不起眼但很要命的細(xì)節(jié)。日志里的時(shí)間戳必須帶毫秒級(jí)精度并且要記錄消息的序列號(hào)這樣復(fù)盤時(shí)才能精確對(duì)齊事件順序。如果時(shí)間戳只精確到秒事后排查兩個(gè)鏈路誰(shuí)先誰(shuí)后根本無(wú)從談起。價(jià)格和數(shù)量這類字段盡量用整數(shù)最小單位存儲(chǔ)不要用浮點(diǎn)數(shù)。浮點(diǎn)數(shù)的精度損失在平時(shí)不會(huì)暴露但極端行情下價(jià)格分開算和合并算會(huì)出現(xiàn)莫名其妙的誤差最后查半天發(fā)現(xiàn)是精度問題。行情消息的序列化格式能用二進(jìn)制就盡量別用純文本。極端行情下序列化和解析的CPU成本是實(shí)實(shí)在在的省下來這一點(diǎn)關(guān)鍵時(shí)刻可能就是決定勝負(fù)的那幾毫秒。還有一個(gè)容易被忽略的坑給WebSocket加上心跳成功率和字節(jié)數(shù)監(jiān)控。因?yàn)樽钗ｋU(xiǎn)的情況不是連接徹底斷開而是“連接好像還活著可數(shù)據(jù)已經(jīng)不新鮮了”。這種模糊狀態(tài)最消耗決策時(shí)間如果沒有心跳監(jiān)控你會(huì)誤以為一切正常?；乜?月23日那一晚我認(rèn)為最值得記住的不是我們最終取得了多好的名次而是整個(gè)團(tuán)隊(duì)在高壓下仍然保持冷靜、按預(yù)案行動(dòng)的狀態(tài)。行情系統(tǒng)和人一樣真正扛住大災(zāi)大難的底氣從來不是臨場(chǎng)發(fā)揮而是日常那些無(wú)聊的、重復(fù)的、不浪漫的準(zhǔn)備。把故障枚舉得足夠多把預(yù)案執(zhí)行得足夠熟等風(fēng)暴真來了你才有資格說一句這次我們扛住了。