在支付系統(tǒng)的復(fù)雜世界里，一次不經(jīng)意的后臺(tái)操作可能引發(fā)災(zāi)難性的后果。本文回顧了一起發(fā)生在大促高峰期間的支付故障案例，揭示了一個(gè)小小的查詢操作如何導(dǎo)致整個(gè)在線交易系統(tǒng)癱瘓。作者隱墨星辰，憑借十余年的支付架構(gòu)設(shè)計(jì)經(jīng)驗(yàn)，深入分析了故障的原因，并提出了有效的解決方案。這篇文章不僅是對(duì)歷史的回顧，也是對(duì)未來(lái)系統(tǒng)設(shè)計(jì)的警示。

大家好，我是隱墨星辰，專注境內(nèi)/跨境支付架構(gòu)設(shè)計(jì)十余年。

今天我們繼續(xù)聊聊那些“可以拖出去祭天”的線上故障案例。這次不是領(lǐng)導(dǎo)人好，保住我小命一條，而是我不夠資格，大老板把我領(lǐng)導(dǎo)的領(lǐng)導(dǎo)給祭天了。

這也是很多年的故事，當(dāng)時(shí)的微服務(wù)框架還沒有現(xiàn)在這么成熟，限流與服務(wù)隔離也沒有現(xiàn)在這么先進(jìn)。

起因只是一次小小的后臺(tái)查詢操作，卻在大促高峰期引發(fā)了連鎖反應(yīng)，讓整個(gè)系統(tǒng)陷入癱瘓。

一次大促開始不久，一位運(yùn)營(yíng)小姐姐在后臺(tái)發(fā)起了一個(gè)后臺(tái)查詢操作，很不幸，觸發(fā)了慢查詢。本來(lái)所有在線交易系統(tǒng)都使用緩存以頂住一些讀壓力，但仍然有小部分請(qǐng)求在緩存中找不到數(shù)據(jù)，穿透到了數(shù)據(jù)庫(kù)，卻遇上這條正在阻塞資源的慢查詢。結(jié)果越來(lái)越多請(qǐng)求堆積，數(shù)據(jù)庫(kù)CPU瞬間飆升至100%。

DBA嘗試kill連接卻無(wú)濟(jì)于事，不得已只能重啟數(shù)據(jù)庫(kù)?？芍貑⒑螅?yàn)樵诰€交易的請(qǐng)求仍在，緩存依舊被打穿，數(shù)據(jù)庫(kù)一恢復(fù)服務(wù)就再度陷入滿載狀態(tài)，陷入惡性循環(huán)。

只能人工先限流，再次重啟，慢慢恢復(fù)流量。等服務(wù)完全恢復(fù)，大促高峰已經(jīng)過去大半。

事后復(fù)盤發(fā)現(xiàn)：當(dāng)時(shí)在線交易對(duì)那部分?jǐn)?shù)據(jù)其實(shí)并非強(qiáng)依賴，即使拿不到那些數(shù)據(jù)，也能繼續(xù)走主流程。但由于缺少弱依賴分析和對(duì)應(yīng)的降級(jí)策略，這塊數(shù)據(jù)竟成了全局堵點(diǎn)。

雖然是一次有點(diǎn)久遠(yuǎn)的故障，背后的思路對(duì)現(xiàn)在的系統(tǒng)設(shè)計(jì)仍然有一些借鑒意義。

先看看問題。

首先是后臺(tái)操作與線上數(shù)據(jù)庫(kù)耦合。大促期間的后臺(tái)查詢沒有隔離環(huán)境，直接在生產(chǎn)DB上執(zhí)行引發(fā)慢SQL，將數(shù)據(jù)庫(kù)資源長(zhǎng)時(shí)間占用，影響在線交易。

其次缺乏弱依賴降級(jí)策略。這部分?jǐn)?shù)據(jù)其實(shí)是“弱依賴”，在線交易不拿到也能繼續(xù)推進(jìn)。但系統(tǒng)實(shí)現(xiàn)成了強(qiáng)依賴，導(dǎo)致前端請(qǐng)求死等結(jié)果，讓線程和資源耗盡。

同時(shí)還缺少自動(dòng)化限流手段，當(dāng)慢SQL導(dǎo)致數(shù)據(jù)庫(kù)處理能力下降，大量請(qǐng)求同時(shí)穿透到后端加劇問題。如果有自動(dòng)化限流策略，可在異常時(shí)快速對(duì)請(qǐng)求進(jìn)行削峰填谷，避免資源被透支。

當(dāng)然最重要是緩存防擊穿策略欠缺。在高并發(fā)場(chǎng)景下，若緩存未命中數(shù)據(jù)且沒有防擊穿策略，一旦后端阻塞，所有請(qǐng)求將同時(shí)穿透數(shù)據(jù)庫(kù)，極易造成資源枯竭。應(yīng)有預(yù)熱緩存、單線程代理查詢、請(qǐng)求隊(duì)列等措施來(lái)防止緩存失效時(shí)大量請(qǐng)求直擊后端。

看到問題，對(duì)應(yīng)的措施就比較簡(jiǎn)單了。

首先是后臺(tái)與線上隔離。在大促期間禁止非所有必要的后臺(tái)操作，即使需要也要單獨(dú)環(huán)境或讀副本、讀緩存，不要直接跑在核心庫(kù)上?？梢栽诖蟠贂r(shí)切換后臺(tái)操作權(quán)限，菜單折疊、權(quán)限下線，減少意外。

其次是弱依賴識(shí)別與降級(jí)。對(duì)主鏈路中的數(shù)據(jù)需求進(jìn)行強(qiáng)弱依賴分析。對(duì)于弱依賴數(shù)據(jù)，一旦獲取超時(shí)或異常，即刻跳過，不阻塞整個(gè)主流程。有損服務(wù)好過無(wú)服務(wù)可用。

然后是限流和熔斷。引入自動(dòng)化限流工具，對(duì)下游資源的請(qǐng)求數(shù)量進(jìn)行控制。當(dāng)下游變慢或掛掉時(shí)，限流可阻止請(qǐng)求洪流加劇問題。

最后是老生常談的緩存防擊穿策略。在高并發(fā)下，緩存穿透會(huì)將數(shù)千上萬(wàn)請(qǐng)求砸向數(shù)據(jù)庫(kù)。應(yīng)提前預(yù)熱數(shù)據(jù)，讓緩存中長(zhǎng)期保留重要信息；對(duì)請(qǐng)求加鎖或隊(duì)列，讓同一時(shí)間只有一個(gè)線程去真正請(qǐng)求后端數(shù)據(jù)，其余等待結(jié)果，從而避免瞬間集中沖擊。

在這個(gè)事故之前，我是沒有想到一個(gè)簡(jiǎn)單的后臺(tái)操作也會(huì)搞死在線交易。從另外一個(gè)側(cè)面看，當(dāng)請(qǐng)求量足夠大時(shí)，很多隱藏的問題就會(huì)暴露，也就是所謂的量變引起質(zhì)變。

一將功成萬(wàn)骨枯，一個(gè)個(gè)線上故障成就了一個(gè)個(gè)經(jīng)驗(yàn)豐富的工程師。

這是《支付通識(shí)》專欄系列文章中的第（11）篇。

深耕境內(nèi)/跨境支付架構(gòu)設(shè)計(jì)十余年，歡迎關(guān)注并星標(biāo)公眾號(hào)“隱墨星辰”，和我一起深入解碼支付系統(tǒng)的方方面面。