什麼是服務雪崩：分布式系統中經常會出現某個基礎服務不可用造成整個系統不可用，這種現象稱為服務雪崩
斷路器（hystrix）的出現就是為了解決服務雪崩
服務雪崩對應策略：
1、流量控制：閘道器限流、使用者互動限流、關閉重試
2、改進快取模式
3、服務自動擴容
4、服務呼叫者降級服務
服務雪崩的原因：
1、機器故障：機器的硬驅動引起的錯誤
2、伺服器負載均衡發生變化：使用者請求量，如阿里的雙十一活動，若沒有提前增加機器預估流量則會造伺服器壓力會驟然增大而掛掉
3、程式錯誤：專案中某段**有bug
解決或緩解服務雪崩：
1、熔斷模式：這種模式主要是參考電路熔斷，如果一條線路電壓過高，保險絲會熔斷，防止火災。放到我們的系統中，如果某個目標服務呼叫慢或者有大量超時，此時，熔斷該服務的呼叫，對於後續呼叫請求，不在繼續呼叫目標服務，直接返回，快速釋放資源。如果目標服務情況好轉則恢復呼叫。
2、隔離模式：這種模式就像對系統請求按型別劃分成乙個個小島的一樣，當某個小島被火少光了，不會影響到其他的小島。例如可以對不同型別的請求使用執行緒池來資源隔離，每種型別的請求互不影響，如果一種型別的請求執行緒資源耗盡，則對後續的該型別請求直接返回，不再呼叫後續資源。這種模式使用場景非常多，例如將乙個服務拆開，對於重要的服務使用單獨伺服器來部署，再或者公司最近推廣的多中心
3、限流模式：上述的熔斷模式和隔離模式都屬於出錯後的容錯處理機制，而限流模式則可以稱為預防模式。限流模式主要是提前對各個型別的請求設定最高的qps閾值，若高於設定的閾值則對該請求直接返回，不再呼叫後續資源。這種模式不能解決服務依賴的問題，只能解決系統整體資源分配問題，因為沒有被限流的請求依然有可能造成雪崩效應
熔斷設計：
在熔斷設計中主要參考hystrix的做法
1、熔斷請求判斷機制演算法：使用無鎖迴圈佇列計數，每個熔斷器預設維護10個bucket，每1秒乙個bucket，每個bucket記錄請求的成功、失敗、超時、拒絕的狀態，預設錯誤超過50%且10秒內超過20個請求進行終端攔截
2、熔斷恢復：對於被熔斷的請求，每隔5秒允許部分請求通過，弱請求都是健康的則對請求健康恢復
3、熔斷報警：對於熔斷的請求列印日誌，異常請求超過某些設定則報警
隔離設計：
1、執行緒池隔離模式：使用乙個執行緒池來儲存當前的請求，執行緒池對請求作處理、設定任務返回處理超時時間，堆積的請求堆積入執行緒池佇列。這種方式需要為每個依賴的服務申請執行緒池，有一定的資源消耗，好處是可以應對突發流量（流量洪峰來臨時，處理不完可將資料儲存到執行緒池隊裡慢慢處理）
2、訊號量隔離模式：使用乙個原子計數器（或訊號量）來記錄當前有多少個執行緒在執行，請求來先判斷計數器的數值，若超過最大的執行緒個數則丟棄改型別的新請求，若不超過則執行計數操作請求來計數+1，請求返回計數器-1，這種方式是嚴格的控制且立即返回模式，無法應對突發流量（流量洪峰來臨時，處理的執行緒超過數量，其它的請求直接返回，不繼續去請求依賴的服務）
超時機制：
等待超時：在任務入佇列時設定任務入佇列時間，並判斷隊頭的任務入佇列時間是否大於超時時間，超過則丟棄任務
執行超時：直接可使用執行緒池提供的get方法
服務降級：
所謂的降級指的是當服務的提供方不可使用的時候，程式不會出現異常，而會出現呼叫本地的操作
服務雪崩效應
服務雪崩效應是一種因服務提供者的不可用導致服務呼叫者的不可用,並將不可用逐漸放大的過程。我把服務雪崩的參與者簡化為服務提供者和服務呼叫者,並將服務雪崩產生的過程分為以下三個階段來分析形成的原因 服務提供者不可用 重試加大流量 服務呼叫者不可用 服務雪崩的每個階段都可能由不同的原因造成,比如造成服務不...
Redis的穿透 雪崩 淘汰策略
從字面上理解，快取穿透就是執行程式擊穿了你的redis快取伺服器，去訪問mysql資料庫 由於redis存在一定的命中概率，進來的請求發現redis中並沒有相關資料或者是沒有命中指定資料，會去資料庫查詢。如果大量請求進來，直接去訪問資料庫服務查詢，資料庫伺服器cpu短時間內會超負載執行，致使資料庫服...
服務雪崩 服務熔斷 服務降級 基礎概念
服務雪崩的概念簡單的理解為，一條服務鏈a 使用者服務 b 訂單服務 c 支付服務 三個服務，分別是a呼叫b，b呼叫c。一般而言任務量最大的是底層服務c。服務c如果掛了 宕機 導致b服務間接也不可用 b服務不可用又間接導致a不可用。這樣這條服務鏈a b c也就全部掛了，就像雪崩一樣，因為乙個服務不可用...