架構師細談：什麼是緩存雪崩？服務器雪崩的場景與解決方案

• 什麼是應用服務雪崩？

雪崩問題

分佈式系統都存在這樣一個問題，因爲網絡的不穩定性，決定了任何一個服務的可用性都不是 100% 的。當網絡不穩定的時候，做爲服務的提供者，自身可能會被拖死，致使服務調用者阻塞，最終可能引起雪崩連鎖效應。

緩存雪崩

當緩存服務器重啓或者大量緩存集中在某一個時間段失效，這樣在失效的時候，也會給後端系統(好比DB)帶來很大壓力，形成數據庫後端故障，從而引發應用服務器雪崩。

雪崩效應產生的幾種場景

• 流量激增：好比異常流量、用戶重試致使系統負載升高；
• 緩存刷新：假設A爲client端，B爲Server端，假設A系統請求都流向B系統，請求超出了B系統的承載能力，就會形成B系統崩潰；
• 程序有Bug：代碼循環調用的邏輯問題，資源未釋放引發的內存泄漏等問題；
• 硬件故障：好比宕機，機房斷電，光纖被挖斷等。
• 數據庫嚴重瓶頸，好比：長事務、sql超時等。
• 線程同步等待：系統間常常採用同步服務調用模式，核心服務和非核心服務共用一個線程池和消息隊列。若是一個核心業務線程調用非核心線程，這個非核心線程交由第三方系統完成，當第三方系統自己出現問題，致使核心線程阻塞，一直處於等待狀態，而進程間的調用是有超時限制的，最終這條線程將斷掉，也可能引起雪崩；

緩存雪崩的解決方案

緩存失效的幾種狀況:

一、緩存服務器掛了

二、高峯期緩存局部失效

三、熱點緩存失效

解決方案：

一、避免緩存集中失效，不一樣的key設置不一樣的超時時間

二、增長互斥鎖，控制數據庫請求，重建緩存。

三、提升緩存的HA，如：redis集羣。

雪崩的總體解決方案

通常狀況對於服務依賴的保護主要有3種解決方案：

（1）熔斷模式

這種模式主要是參考電路熔斷，若是一條線路電壓太高，保險絲會熔斷，防止火災。放到咱們的系統中，若是某個目標服務調用慢或者有大量超時，此時，熔斷該服務的調用，對於後續調用請求，不在繼續調用目標服務，直接返回，快速釋放資源。若是目標服務狀況好轉則恢復調用。

重點監控的機器性能指標

• cpu(Load) cpu使用率/負載
• memory 內存
• mysql監控長事務(這裏與sql查詢超時是緊密結合的，須要重點監控)
• sql超時
• 線程數等

總之，除了cpu、內存、線程數外，重點監控數據庫端的長事務、sql超時等，絕大多數應用服務器發生的雪崩場景，都是來源於數據庫端的性能瓶頸，從而先引發數據庫端大量瓶頸，最終拖累應用服務器也發生雪崩，最後就是大面積的雪崩。

（2）隔離模式

這種模式就像對系統請求按類型劃分紅一個個小島的同樣，當某個小島被火少光了，不會影響到其餘的小島。

例如能夠對不一樣類型的請求使用線程池來資源隔離，每種類型的請求互不影響，若是一種類型的請求線程資源耗盡，則對後續的該類型請求直接返回，再也不調用後續資源。這種模式使用場景很是多，例如將一個服務拆開，對於重要的服務使用單獨服務器來部署，再或者公司最近推廣的多中心。

（3）限流模式

上述的熔斷模式和隔離模式都屬於出錯後的容錯處理機制，而限流模式則能夠稱爲預防模式。限流模式主要是提早對各個類型的請求設置最高的QPS閾值，若高於設置的閾值則對該請求直接返回，再也不調用後續資源。這種模式不能解決服務依賴的問題，只能解決系統總體資源分配問題，由於沒有被限流的請求依然有可能形成雪崩效應。

熔斷設計

在熔斷的設計主要參考了hystrix的作法。其中最重要的是三個模塊：熔斷請求判斷算法、熔斷恢復機制、熔斷報警

（1）熔斷請求判斷機制算法：使用無鎖循環隊列計數，每一個熔斷器默認維護10個bucket，每1秒一個bucket，每一個blucket記錄請求的成功、失敗、超時、拒絕的狀態，默認錯誤超過50%且10秒內超過20個請求進行中斷攔截。

（2）熔斷恢復：對於被熔斷的請求，每隔5s容許部分請求經過，若請求都是健康的（RT<250ms）則對請求健康恢復。

（3）熔斷報警：對於熔斷的請求打日誌，異常請求超過某些設定則報警。

隔離設計

隔離的方式通常使用兩種

（1）線程池隔離模式：使用一個線程池來存儲當前的請求，線程池對請求做處理，設置任務返回處理超時時間，堆積的請求堆積入線程池隊列。這種方式須要爲每一個依賴的服務申請線程池，有必定的資源消耗，好處是能夠應對突發流量（流量洪峯來臨時，處理不完可將數據存儲到線程池隊裏慢慢處理）

（2）信號量隔離模式：使用一個原子計數器（或信號量）來記錄當前有多少個線程在運行，請求來先判斷計數器的數值，若超過設置的最大線程個數則丟棄改類型的新請求，若不超過則執行計數操做請求來計數器+1，請求返回計數器-1。這種方式是嚴格的控制線程且當即返回模式，沒法應對突發流量（流量洪峯來臨時，處理的線程超過數量，其餘的請求會直接返回，不繼續去請求依賴的服務）

超時機制設計

（1）超時分兩種，一種是請求的等待超時，一種是請求運行超時。

（2）等待超時：在任務入隊列時設置任務入隊列時間，並判斷隊頭的任務入隊列時間是否大於超時時間，超過則丟棄任務。

（3）運行超時：直接可以使用線程池提供的get方法。

如何提早發現雪崩

就是首先讓系統不雪崩，而後經過監控發現請求正在接近或者超過閥值，而後再根據具體狀況處理，這個接近或者超過閥值的過程，能夠稱爲 「提早發現雪崩」。

以上就是應用服務雪崩的場景以及技術方案總結。

順便在此給你們推薦一個Java架構方面的交流學習羣：698581634，裏面會分享一些資深架構師錄製的視頻錄像：有Spring，MyBatis，Netty源碼分析，高併發、高性能、分佈式、微服務架構的原理，JVM性能優化這些成爲架構師必備的知識體系，在這個羣裏會有你須要的內容  朋友們請抓緊時間加入進來吧。