騰訊后臺開發(fā)技術(shù)總監(jiān)淺談過載保護(hù) 小心雪崩效應(yīng)
雪球：
對于時延敏感的服務(wù)，當(dāng)外部請求超過系統(tǒng)處理能力，如果系統(tǒng)沒有做相應(yīng)保護(hù)，可能導(dǎo)致歷史累計的超時請求達(dá)到一定規(guī)模，像雪球一樣形成惡性循環(huán)。由于系統(tǒng)處理的每個請求都因為超時而無效，系統(tǒng)對外呈現(xiàn)的服務(wù)能力為0，且這種情況下不能自動恢復(fù)。
騰訊后臺開發(fā)技術(shù)總監(jiān)bison，給大家分享了非常精彩的過載保護(hù)，其看似簡單，但是要做好并不容易。這里用兩個曾經(jīng)經(jīng)歷的反面案例，給出過載保護(hù)的直觀展現(xiàn)，并附上一點感想。
案例一 基本情況
如下圖，進(jìn)程A是一個單進(jìn)程系統(tǒng)，通過udp套接字接收前端請求進(jìn)行處理。在處理過程中，需要訪問后端系統(tǒng)B，是同步的方式訪問后端系統(tǒng)B，根據(jù)后端系統(tǒng)B的SLA，超時時間設(shè)置是100ms。前端用戶請求的超時時間是1s。
進(jìn)程A的時序是：
Step1: 從socket接收緩沖區(qū)接收用戶請求
Step2: 進(jìn)行本地邏輯處理
Step3: 發(fā)送請求到后端系統(tǒng)B
Step4: 等待后端系統(tǒng)B返回
Step5: 接收后端系統(tǒng)B的應(yīng)答
Step6: 應(yīng)答前端用戶，回到step1處理下一個請求
正常情況下的負(fù)載
正常情況下：
1、前端請求報文大小約100Bytes。前端請求的峰值每分鐘1800次，即峰值每秒30次。
2、后端系統(tǒng)B并行能力較高，每秒可以處理10000次以上，絕大多數(shù)請求處理時延在20ms內(nèi)。
3、進(jìn)程A在處理請求的時候，主要時延是在等待后端系統(tǒng)B，其他本地運算耗時非常少，小于1ms
這個時候，我們可以看出，系統(tǒng)工作良好，因為處理時延在20ms內(nèi)，每秒進(jìn)程A每秒中可以處理50個請求，足以將用戶每秒峰值30個請求及時處理完。
導(dǎo)火索
某天，后端系統(tǒng)B進(jìn)行了新特性發(fā)布，由于內(nèi)部邏輯變復(fù)雜，導(dǎo)致每個請求處理時延從20ms延長至50ms，根據(jù)sla的100ms超時時間，這個時延仍然在正常范圍內(nèi)。當(dāng)用戶請求達(dá)到峰值時間點時，災(zāi)難出現(xiàn)了，用戶每次操作都是“服務(wù)器超時無響應(yīng)”，整個服務(wù)不可用。
過載分析
當(dāng)后端系統(tǒng)B處理時延延長至50ms的時候，進(jìn)程A每秒只能處理20個請求（1s / 50ms = 20 ）。小于正常情況下的用戶請求峰值30次/s。這個時候操作失敗的用戶往往會重試，我們觀察到前端用戶請求增加了6倍以上，達(dá)到200次/s，是進(jìn)程A最 大處理能力（20次/s）的10倍！
這個時候為什么所有用戶發(fā)現(xiàn)操作都是失敗的呢？ 為什么不是1/10的用戶發(fā)現(xiàn)操作能成功呢？ 因為請求量和處理能力之間巨大的差異使得5.6s內(nèi)就迅速填滿了socket接收緩沖區(qū)（平均能緩存1000個請 求，1000/(200-20)=5.6s），并且該緩沖區(qū)將一直保持滿的狀態(tài)。這意味著，一個請求被追加到緩沖區(qū)里后，要等待50s（緩存1000個請 求，每秒處理20個，需要50s）后才能被進(jìn)程A 取出來處理，這個時候用戶早就看到操作超時了。換句話說，進(jìn)程A每次處理的請求，都已經(jīng)是50s以前產(chǎn)生的，進(jìn)程A一直在做無用功。雪球產(chǎn)生了。
案例二 基本情況
前端系統(tǒng)C通過udp訪問后端serverD，后端server D的udp套接字緩沖區(qū)為4MB，每個請求大小約400字節(jié)。后端serverD偶爾處理超時情況下，前端系統(tǒng)C會重試，最多重試2次。
正常情況下的負(fù)載
正常情況，后端serverD單機(jī)收到請求峰值為300次/s，后端serverD單機(jī)處理能力是每秒1500次，時延10ms左右。這個時候工作正常。
導(dǎo)火索
由于產(chǎn)品特性（例如提前通知大量用戶，未來某某時刻將進(jìn)行一項秒殺活動；類似奧運門票，大量用戶提前得知信息：某日開始發(fā)售門票），大量的用戶聚集在同 一時刻發(fā)起了大量請求，超出了后臺serverD的最大負(fù)載能力。操作響應(yīng)失敗的用戶又重試， 中間系統(tǒng)的重試，進(jìn)一步帶來了更大量的請求(正常情況下的9倍)。導(dǎo)致所有用戶操作都是失敗的。
過載分析
只是導(dǎo)火索不一樣，同案例一，巨大的請求和處理能力之間的鴻溝，導(dǎo)致后端serverD的4M大小的接收緩沖區(qū)迅速填滿（4秒就填滿），且過載時間內(nèi)， 接收緩沖區(qū)一直都是滿的。而處理完緩沖區(qū)內(nèi)的請求，ServerD需要6秒以上（4MB / 400 / 1500 = 6.7S）。所以serverD處理的請求都是6s之前放入緩沖區(qū)的，而該請求在最前端早已經(jīng)超時。雪球形成了。
啟示
1、 每 個系統(tǒng)，自己的最大處理能力是多少要做到清清楚楚。例如案例一中的前端進(jìn)程A，他的最大處理能力不是50次/s，也不是20次/S，而是10次/S。因為 它是單進(jìn)程同步的訪問后端B， 且訪問后端B的超時時間是100ms，所以他的處理能力就是1S/100ms=10次/S。而平時處理能力表現(xiàn)為50次/S，只是運氣好。
2、 每個系統(tǒng)要做好自我保護(hù)，量力而為，而不是盡力而為。對于超出自己處理能力范圍的請求，要勇于拒絕。
3、 每個系統(tǒng)要有能力發(fā)現(xiàn)哪些是有效的請求，哪些是無效的請求。上面兩個案例中，過載的系統(tǒng)都不具備這中慧眼，逮著請求做死的處理，雪球時其實是做無用功。
4、 前端系統(tǒng)有保護(hù)后端系統(tǒng)的義務(wù)，sla中承諾多大的能力，就只給到后端多大的壓力。這就要求每一個前后端接口的地方，都有明確的負(fù)載約定，一環(huán)扣一環(huán)。
5、 當(dāng)過載發(fā)生時，該拒絕的請求（1、超出整個系統(tǒng)處理能力范圍的；2、已經(jīng)超時的無效請求）越早拒絕越好。就像上海機(jī)場到市區(qū)的高速上，剛出機(jī)場就有電子公示牌顯示，進(jìn)入市區(qū)某某路段擁堵，請繞行。
6、 對于用戶的重試行為，要適當(dāng)?shù)难泳彙＠绲卿洶l(fā)現(xiàn)后端響應(yīng)失敗，再重新展現(xiàn)登錄頁面前，可以適當(dāng)延時幾秒鐘，并展現(xiàn)進(jìn)度條等友好界面。當(dāng)多次重試還失敗的情況下，要安撫用戶。
7、 產(chǎn)品特性設(shè)計和發(fā)布上，要盡量避免某個時刻導(dǎo)致大量用戶集體觸發(fā)某些請求的設(shè)計。發(fā)布的時候注意灰度。
8、 中間層server對后端發(fā)送請求，重試機(jī)制要慎用，一定要用的話要有嚴(yán)格頻率控制。
9、 當(dāng)雪球發(fā)生了，直接清空雪球隊列（例如重啟進(jìn)程可以清空socket 緩沖區(qū)）可能是快速恢復(fù)的有效方法。
10、過載保護(hù)很重要的一點，不是說要加強(qiáng)系統(tǒng)性能、容量，成功應(yīng)答所有請求，而是保證在高壓下，系統(tǒng)的服務(wù)能力不要陡降到0，而是頑強(qiáng)的對外展現(xiàn)最大有效處理能力。
對于“每個系統(tǒng)要有能力發(fā)現(xiàn)哪些是有效的請求，哪些是雪球無效的請求”，這里推薦一種方案：在該系統(tǒng)每個機(jī)器上新增一個進(jìn)程：interface進(jìn)程。 Interface進(jìn)程能夠快速的從socket緩沖區(qū)中取得請求，打上當(dāng)前時間戳，壓入channel。業(yè)務(wù)處理進(jìn)程從channel中獲取請求和該請 求的時間戳，如果發(fā)現(xiàn)時間戳早于當(dāng)前時間減去超時時間（即已經(jīng)超時，處理也沒有意義），就直接丟棄該請求，或者應(yīng)答一個失敗報文。
Channel是一個先進(jìn)先出的通信方式，可以是socket，也可以是共享內(nèi)存、消息隊列、或者管道，不限。
Socket緩沖區(qū)要設(shè)置合理，如果過大，導(dǎo)致及時interface進(jìn)程都需要處理長時間才能清空該隊列，就不合適了。建議的大小上限是：緩存住超時時間內(nèi)interface進(jìn)程能夠處理掉的請求個數(shù)（注意考慮網(wǎng)絡(luò)通訊中的元數(shù)據(jù)）。
原創(chuàng)文章，轉(zhuǎn)載請注明： 文章地址騰訊后臺開發(fā)技術(shù)總監(jiān)淺談過載保護(hù) 小心雪崩效應(yīng)
【編輯推薦】
