騰訊後臺開發技術總監淺談過載保護 小心雪崩效應

     轉載地址：http://www.chinaz.com/news/2012/0510/250784.shtml

摘要： 每個系統，都有自己的最大處理能力，後臺技術人員對此必須很清楚，且要注意自我保護，不然就會被雪球壓垮，出現雪崩。

雪球：

對於時延敏感的服務，當外部請求超過系統處理能力，如果系統沒有做相應保護，可能導致歷史累計的超時請求達到一定規模，像雪球一樣形成惡性迴圈。由於系統處理的每個請求都因為超時而無效，系統對外呈現的服務能力為0，且這種情況下不能自動恢復。

騰訊後臺開發技術總監bison，給大家分享了非常精彩的過載保護，其看似簡單，但是要做好並不容易。這裡用兩個曾經經歷的反面案例，給出過載保護的直觀展現，並附上一點感想。

案例一 基本情況

如下圖，程式A是一個單程式系統，通過udp套接字接收前端請求進行處理。在處理過程中，需要訪問後端系統B，是同步的方式訪問後端系統B，根據後端系統B的SLA，超時時間設定是100ms。前端使用者請求的超時時間是1s。

程式A的時序是：

Step1： 從socket接收緩衝區接收使用者請求

Step2： 進行本地邏輯處理

Step3： 傳送請求到後端系統B

Step4： 等待後端系統B返回

Step5： 接收後端系統B的應答

Step6： 應答前端使用者，回到step1處理下一個請求

正常情況下的負載

正常情況下：

1、前端請求報文大小約100Bytes。前端請求的峰值每分鐘1800次，即峰值每秒30次。

2、後端系統B並行能力較高，每秒可以處理10000次以上，絕大多數請求處理時延在20ms內。

3、程式A在處理請求的時候，主要時延是在等待後端系統B，其他本地運算耗時非常少，小於1ms

這個時候，我們可以看出，系統工作良好，因為處理時延在20ms內，每秒程式A每秒中可以處理50個請求，足以將使用者每秒峰值30個請求及時處理完。

導火索

某天，後端系統B進行了新特性發布，由於內部邏輯變複雜，導致每個請求處理時延從20ms延長至50ms，根據sla的100ms超時時間，這個時延仍然在正常範圍內。當使用者請求達到峰值時間點時，災難出現了，使用者每次操作都是“伺服器超時無響應”，整個服務不可用。

過載分析

當後端系統B處理時延延長至50ms的時候，程式A每秒只能處理20個請求（1s / 50ms = 20 ）。小於正常情況下的使用者請求峰值30次/s。這個時候操作失敗的使用者往往會重試，我們觀察到前端使用者請求增加了6倍以上，達到200次/s，是程式A最 大處理能力（20次/s）的10倍！

這個時候為什麼所有使用者發現操作都是失敗的呢？ 為什麼不是1/10的使用者發現操作能成功呢？ 因為請求量和處理能力之間巨大的差異使得5.6s內就迅速填滿了socket接收緩衝區（平均能快取1000個請 求，1000/（200-20）=5.6s），並且該緩衝區將一直保持滿的狀態。這意味著，一個請求被追加到緩衝區裡後，要等待50s（快取1000個請 求，每秒處理20個，需要50s）後才能被程式A 取出來處理，這個時候使用者早就看到操作超時了。換句話說，程式A每次處理的請求，都已經是50s以前產生的，程式A一直在做無用功。雪球產生了。

案例二 基本情況

前端系統C通過udp訪問後端serverD，後端server D的udp套接字緩衝區為4MB，每個請求大小約400位元組。後端serverD偶爾處理超時情況下，前端系統C會重試，最多重試2次。

正常情況下的負載

正常情況，後端serverD單機收到請求峰值為300次/s，後端serverD單機處理能力是每秒1500次，時延10ms左右。這個時候工作正常。

導火索

由於產品特性（例如提前通知大量使用者，未來某某時刻將進行一項秒殺活動；類似奧運門票，大量使用者提前得知資訊：某日開始發售門票），大量的使用者聚集在同 一時刻發起了大量請求，超出了後臺serverD的最大負載能力。操作響應失敗的使用者又重試， 中間系統的重試，進一步帶來了更大量的請求（正常情況下的9倍）。導致所有使用者操作都是失敗的。

過載分析

只是導火索不一樣，同案例一，巨大的請求和處理能力之間的鴻溝，導致後端serverD的4M大小的接收緩衝區迅速填滿（4秒就填滿），且過載時間內， 接收緩衝區一直都是滿的。而處理完緩衝區內的請求，ServerD需要6秒以上（4MB / 400 / 1500 = 6.7S）。所以serverD處理的請求都是6s之前放入緩衝區的，而該請求在最前端早已經超時。雪球形成了。

啟示

1、 每 個系統，自己的最大處理能力是多少要做到清清楚楚。例如案例一中的前端程式A，他的最大處理能力不是50次/s，也不是20次/S，而是10次/S。因為 它是單程式同步的訪問後端B， 且訪問後端B的超時時間是100ms，所以他的處理能力就是1S/100ms=10次/S。而平時處理能力表現為50次/S，只是運氣好。

2、 每個系統要做好自我保護，量力而為，而不是盡力而為。對於超出自己處理能力範圍的請求，要勇於拒絕。

3、 每個系統要有能力發現哪些是有效的請求，哪些是無效的請求。上面兩個案例中，過載的系統都不具備這中慧眼，逮著請求做死的處理，雪球時其實是做無用功。

4、 前端系統有保護後端系統的義務，sla中承諾多大的能力，就只給到後端多大的壓力。這就要求每一個前後端介面的地方，都有明確的負載約定，一環扣一環。

5、 當過載發生時，該拒絕的請求（1、超出整個系統處理能力範圍的；2、已經超時的無效請求）越早拒絕越好。就像上海機場到市區的高速上，剛出機場就有電子公示牌顯示，進入市區某某路段擁堵，請繞行。

6、 對於使用者的重試行為，要適當的延緩。例如登入發現後端響應失敗，再重新展現登入頁面前，可以適當延時幾秒鐘，並展現進度條等友好介面。當多次重試還失敗的情況下，要安撫使用者。

7、 產品特性設計和釋出上，要儘量避免某個時刻導致大量使用者集體觸發某些請求的設計。釋出的時候注意灰度。

8、 中間層server對後端傳送請求，重試機制要慎用，一定要用的話要有嚴格頻率控制。

9、 當雪球發生了，直接清空雪球佇列（例如重啟程式可以清空socket 緩衝區）可能是快速恢復的有效方法。

對於“每個系統要有能力發現哪些是有效的請求，哪些是雪球無效的請求”，這裡推薦一種方案：在該系統每個機器上新增一個程式：interface程式。 Interface程式能夠快速的從socket緩衝區中取得請求，打上當前時間戳，壓入channel。業務處理程式從channel中獲取請求和該請 求的時間戳，如果發現時間戳早於當前時間減去超時時間（即已經超時，處理也沒有意義），就直接丟棄該請求，或者應答一個失敗報文。

10、過載保護很重要的一點，不是說要加強系統效能、容量，成功應答所有請求，而是保證在高壓下，系統的服務能力不要陡降到0，而是頑強的對外展現最大有效處理能力。

Channel是一個先進先出的通訊方式，可以是socket，也可以是共享記憶體、訊息佇列、或者管道，不限。

Socket緩衝區要設定合理，如果過大，導致及時interface程式都需要處理長時間才能清空該佇列，就不合適了。建議的大小上限是：快取住超時時間內interface程式能夠處理掉的請求個數（注意考慮網路通訊中的後設資料）。