每個系統，都有自己的最大處理能力，後台技術人員對此必須很清楚，且要注意自我保護，不然就會被雪球壓垮，出現雪崩。
對於時延敏感的服務，當外部請求超過系統處理能力，如果系統沒有做相應保護，可能導致歷史累計的超時請求達到一定規模，像雪球一樣形成惡性迴圈。由於系統處理的每個請求都因為超時而無效，系統對外呈現的服務能力為0，且這種情況下不能自動恢復。
如下圖，程序a是乙個單程序系統，通過udp套接字接收前端請求進行處理。在處理過程中，需要訪問後端系統b，是同步的方式訪問後端系統b，根據後端系統b的sla，超時時間設定是100ms。前端使用者請求的超時時間是1s。
step1: 從socket接收緩衝區接收使用者請求
step2: 進行本地邏輯處理
step3: 傳送請求到後端系統b
step4: 等待後端系統b返回
step5: 接收後端系統b的應答
step6: 應答前端使用者，回到step1處理下乙個請求
正常情況下：
前端請求報文大小約100bytes。前端請求的峰值每分鐘1800次，即峰值每秒30次。
後端系統b並行能力較高，每秒可以處理10000次以上，絕大多數請求處理時延在20ms內。
程序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之前放入緩衝區的，而該請求在最前端早已經超時。雪球形成了。
對於「每個系統要有能力發現哪些是有效的請求，哪些是雪球無效的請求」，這裡推薦一種方案：在該系統每個機器上新增乙個程序：inte***ce程序。inte***ce程序能夠快速的從socket緩衝區中取得請求，打上當前時間戳，壓入channel。業務處理程序從channel中獲取請求和該請求的時間戳，如果發現時間戳早於當前時間減去超時時間（即已經超時，處理也沒有意義），就直接丟棄該請求，或者應答乙個失敗報文。
channel是乙個先進先出的通訊方式，可以是socket，也可以是共享記憶體、訊息佇列、或者管道，不限。
架構高可用 服務保護
服務降級 限流是服務降級的一種，限制系統輸出和輸入流量從而保護系統。系統吞吐量是一定的，可以通過壓力測試得到。有可能會超過系統閾值，為了保證系統的穩定，需要採取一些措施，比如，延遲處理，拒絕處理，部分拒絕處理等 計數器優勢 控制單位時間內的請求數量，簡單粗暴 劣勢 無法應對極短時間裡的突發流量 滑動...
微服務架構 7 安全保護
目錄2.基於 oauth2 的安全認證 3.構建使用 jwt 令牌儲存的 oauth2 安全認證 最後 spring microservices in action spring cloud alibaba 微服務原理與實戰 b站 尚矽谷 springcloud 框架開發教程 周陽 安全性是暴露由許...
一些過載保護，防止雪崩的方法
一般介面都有乙個最大處理能力，比如每秒處理n萬個請求。正常情況下，在前端允許的時延內，後端介面都能處理完請求。但到了類似搶購小公尺神機的場景下，後端的介面一般會承受超出平時請求量幾十幾百甚至幾萬倍的請求量，而且這寫請求全部集中在一段時間內，稱之為過載時間。這段時間內，後端介面的處理能力達到了極限，不...