服務雪崩效應是一種因服務提供者的不可用導致服務呼叫者的不可用,並將不可用逐漸放大的過程。
我把服務雪崩的參與者簡化為服務提供者和服務呼叫者,並將服務雪崩產生的過程分為以下三個階段來分析形成的原因:
服務提供者不可用
重試加大流量
服務呼叫者不可用
服務雪崩的每個階段都可能由不同的原因造成, 比如造成服務不可用的原因有:
硬體故障
程式bug
快取擊穿
使用者大量請求
硬體故障可能為硬體損壞造成的伺服器主機宕機, 網路硬體故障造成的服務提供者的不可訪問.
快取擊穿一般發生在快取應用重啟, 所有快取被清空時，以及短時間內大量快取失效時。大量的快取不命中,，使請求直擊後端,造成服務提供者超負荷執行,引起服務不可用。
在秒殺和大促開始前,如果準備不充分，使用者發起大量請求也會造成服務提供者的不可用.
而形成 重試加大流量 的原因有：
使用者重試
**邏輯重試
在服務提供者不可用後, 使用者由於忍受不了介面上長時間的等待，而不斷重新整理頁面甚至提交表單。
服務呼叫端的會存在大量服務異常後的重試邏輯.。
這些重試都會進一步加大請求流量。
最後， 服務呼叫者不可用 產生的主要原因是：
同步等待造成的資源耗盡
當服務呼叫者使用同步呼叫時，會產生大量的等待執行緒占用系統資源。一旦執行緒資源被耗盡，服務呼叫者提供的服務也將處於不可用狀態，於是服務雪崩效應產生了。
針對造成服務雪崩的不同原因，可以使用不同的應對策略：
流量控制
改進快取模式
服務自動擴容
服務呼叫者降級服務
流量控制 的具體措施包括：
閘道器限流
使用者互動限流
關閉重試
因為nginx的高效能，目前一線網際網路公司大量採用nginx+lua的閘道器進行流量控制, 由此而來的openresty也越來越熱門。
使用者互動限流的具體措施有：
1. 採用載入動畫，提高使用者的忍耐等待時間。
2. 提交按鈕新增強制等待時間機制。
改進快取模式 的措施包括:
快取預載入
同步改為非同步重新整理
服務自動擴容 的措施主要有:
aws的auto scaling
服務呼叫者降級服務 的措施包括:
資源隔離
對依賴服務進行分類
不可用服務的呼叫快速失敗
資源隔離主要是對呼叫服務的執行緒池進行隔離.
我們根據具體業務，將依賴服務分為： 強依賴和弱依賴。強依賴服務不可用會導致當前業務中止,而弱依賴服務的不可用不會導致當前業務的中止。
不可用服務的呼叫快速失敗一般通過超時機制，熔斷器和熔斷後的降級方法來實現.
基於Hystrix解決服務雪崩效應原理
1 服務降級 在高併發的情況下 防止使用者一直等待，使用服務降級方式 返回乙個友好提示直接給客戶端，不回去處理請求，呼叫fallback本地方法 目的是為了更好的使用者體驗感 秒殺 當前請求人數過多，請稍後重試 在tomcat中沒有執行緒進行處理客戶端請求的時候，不應該讓使用者一直轉圈等待 2 服務...
災難性雪崩效應
什麼是服務災難性雪崩效應 1 什麼是災難性雪崩效應？乙個伺服器不能正常工作，則有可能影響很多伺服器癱瘓 2 造成雪崩原因是什麼？如何解決災難性雪崩效應 1 解決災難性雪崩效應有哪些方式？1.降級2.快取3.請求合併4.熔斷5.隔離 2 每種方式的特點是什麼？降級 超時降級 資源不足時 執行緒或訊號量...
redis的快取穿透和雪崩效應
快取穿透 在redis中一般用key去快取中查詢所對應的value值，如果不存在則去後端系統 入db 一些惡意的請求會故意查詢不存在的key,請求量很大，對後台系統的造成很大的壓力，這就是快取穿透 如何避免 1.對查詢結果為null的key進行快取,快取時間稍短了一些，或者該key對應的資料inse...