（1）某幾個機器故障：例如機器的硬驅動引起的錯誤，或者一些特定的機器上出現一些的bug（如，記憶體中斷或者死鎖）。
（2）伺服器負載發生變化：某些時候服務會因為使用者行為造成請求無法及時處理從而導致雪崩，例如阿里的雙十一活動，若沒有提前增加機器預估流量則會造伺服器壓力會驟然增大二掛掉。
（3）人為因素：比如**中的路徑在某個時候出現bug
一般情況對於服務依賴的保護主要有3中解決方案：
（1）熔斷模式：這種模式主要是參考電路熔斷，如果一條線路電壓過高，保險絲會熔斷，防止火災。放到我們的系統中，如果某個目標服務呼叫慢或者有大量超時，此時，熔斷該服務的呼叫，對於後續呼叫請求，不在繼續呼叫目標服務，直接返回，快速釋放資源。如果目標服務情況好轉則恢復呼叫。
（2）隔離模式：這種模式就像對系統請求按型別劃分成乙個個小島的一樣，當某個小島被火少光了，不會影響到其他的小島。例如可以對不同型別的請求使用執行緒池來資源隔離，每種型別的請求互不影響，如果一種型別的請求執行緒資源耗盡，則對後續的該型別請求直接返回，不再呼叫後續資源。這種模式使用場景非常多，例如將乙個服務拆開，對於重要的服務使用單獨伺服器來部署，再或者公司最近推廣的多中心。
（3）限流模式：上述的熔斷模式和隔離模式都屬於出錯後的容錯處理機制，而限流模式則可以稱為預防模式。限流模式主要是提前對各個型別的請求設定最高的qps閾值，若高於設定的閾值則對該請求直接返回，不再呼叫後續資源。這種模式不能解決服務依賴的問題，只能解決系統整體資源分配問題，因為沒有被限流的請求依然有可能造成雪崩效應。
（1）熔斷請求判斷機制演算法：使用無鎖迴圈佇列計數，每個熔斷器預設維護10個bucket，每1秒乙個bucket，每個blucket記錄請求的成功、失敗、超時、拒絕的狀態，預設錯誤超過50%且10秒內超過20個請求進行中斷攔截。
（2）熔斷恢復：對於被熔斷的請求，每隔5s允許部分請求通過，若請求都是健康的（rt<250ms）則對請求健康恢復。
（3）熔斷報警：對於熔斷的請求打日誌，異常請求超過某些設定則報警
隔離的方式一般使用兩種
（1）執行緒池隔離模式：使用乙個執行緒池來儲存當前的請求，執行緒池對請求作處理，設定任務返回處理超時時間，堆積的請求堆積入執行緒池佇列。這種方式需要為每個依賴的服務申請執行緒池，有一定的資源消耗，好處是可以應對突發流量（流量洪峰來臨時，處理不完可將資料儲存到執行緒池隊裡慢慢處理）
（2）訊號量隔離模式：使用乙個原子計數器（或訊號量）來記錄當前有多少個執行緒在執行，請求來先判斷計數器的數值，若超過設定的最大執行緒個數則丟棄改型別的新請求，若不超過則執行計數操作請求來計數器+1，請求返回計數器-1。這種方式是嚴格的控制線程且立即返回模式，無法應對突發流量（流量洪峰來臨時，處理的執行緒超過數量，其他的請求會直接返回，不繼續去請求依賴的服務）
超時分兩種，一種是請求的等待超時，一種是請求執行超時。
等待超時：在任務入佇列時設定任務入佇列時間，並判斷隊頭的任務入佇列時間是否大於超時時間，超過則丟棄任務。
執行超時：直接可使用執行緒池提供的get方法
快取雪崩，快取穿透解決方案
負載過高，甚至宕機。解決思路 1，採用加鎖計數，或者使用合理的佇列數量來避免快取失效時對資料庫造成太大的壓力。這種辦法雖然能緩解資料庫的壓力，但是同時又降低了系統的吞吐量。2，分析使用者行為，盡量讓失效時間點均勻分布。避免快取雪崩的出現。3，如果是因為某台快取伺服器宕機，可以考慮做主備，比如 red...
快取雪崩，快取穿透解決方案
快取雪崩可能是因為資料未載入到快取中，或者快取同一時間大面積的失效，從而導致所有請求都去查資料庫，導致資料庫cpu和記憶體負載過高，甚至宕機。解決思路 1，採用加鎖計數，或者使用合理的佇列數量來避免快取失效時對資料庫造成太大的壓力。這種辦法雖然能緩解資料庫的壓力，但是同時又降低了系統的吞吐量。2，分...
快取雪崩，快取穿透解決方案
解決辦法 對所有可能查詢的引數以hash形式儲存，在控制層先進行校驗，不符合則丟棄。2.快取失效 如果快取集中在一段時間內失效，db的壓力凸顯。這個沒有完美解決辦法，但可以分析使用者行為，盡量讓失效時間點均勻分布。快取雪崩可能是因為資料未載入到快取中，或者快取同一時間大面積的失效，從而導致所有請求都...