高并發架構系列：如何解決Redis雪崩、穿透、并發等5大難題

一、緩存雪崩

資料未加載到緩存中，或者緩存同一時間大面積的失效，進而導緻所有請求都去查資料庫，導緻資料庫CPU和記憶體負載過高，甚至當機。

比如一個雪崩的簡單過程：

1、redis叢集大面積故障；

2、緩存失效，但依然大量請求通路緩存服務redis；

3、redis大量失效後，大量請求轉向到mysql資料庫；

4、mysql的調用量暴增，很快就扛不住了，甚至直接當機；

5、由于大量的應用服務依賴mysql和redis的服務，這個時候很快會演變成各伺服器叢集的雪崩，最後網站徹底崩潰。

如何預防緩存雪崩：

1.緩存的高可用性

緩存層設計成高可用，防止緩存大面積故障。即使個别節點、個别機器、甚至是機房宕掉，依然可以提供服務，例如 Redis Sentinel 和 Redis Cluster 都實作了高可用。

2.緩存降級

可以利用ehcache等本地緩存(暫時支援)，但主要還是對源服務通路進行限流、資源隔離（熔斷）、降級等。

當通路量劇增、服務出現問題仍然需要保證服務還是可用的。系統可以根據一些關鍵資料進行自動降級，也可以配置開關實作人工降級，這裡會涉及到運維的配合。

降級的最終目的是保證核心服務可用，即使是有損的。

比如推薦服務中，很多都是個性化的需求，假如個性化需求不能提供服務了，可以降級補充熱點資料，不至于造成前端頁面是個大空白。

在進行降級之前要對系統進行梳理，比如：哪些業務是核心(必須保證)，哪些業務可以容許暫時不提供服務(利用靜态頁面替換)等，以及配合伺服器核心名額，來後設定整體預案，比如：

（1）一般：比如有些服務偶爾因為網絡抖動或者服務正在上線而逾時，可以自動降級；

（2）警告：有些服務在一段時間内成功率有波動（如在95~100%之間），可以自動降級或人工降級，并發送告警；

（3）錯誤：比如可用率低于90%，或者資料庫連接配接池被打爆了，或者通路量突然猛增到系統能承受的最大閥值，此時可以根據情況自動降級或者人工降級；

（4）嚴重錯誤：比如因為特殊原因資料錯誤了，此時需要緊急人工降級。

3.Redis備份和快速預熱

1)Redis資料備份和恢複

2)快速緩存預熱

4.提前演練

最後，建議還是在項目上線前，演練緩存層宕掉後，應用以及後端的負**載情況以及可能出現的問題，對高可用提前預演，提前發現問題。

二、緩存穿透**

緩存穿透是指查詢一個一不存在的資料。例如：從緩存redis沒有命中，需要從mysql資料庫查詢，查不到資料則不寫入緩存，這将導緻這個不存在的資料每次請求都要到資料庫去查詢，造成緩存穿透。

解決思路：

如果查詢資料庫也為空，直接設定一個預設值存放到緩存，這樣第二次到緩沖中擷取就有值了，而不會繼續通路資料庫。設定一個過期時間或者當有值的時候将緩存中的值替換掉即可。

可以給key設定一些格式規則，然後查詢之前先過濾掉不符合規則的Key。

三、緩存并發

這裡的并發指的是多個redis的client同時set key引起的并發問題。其實redis自身就是單線程操作，多個client并發操作，按照先到先執行的原則，先到的先執行，其餘的阻塞。當然，另外的解決方案是把redis.set操作放在隊列中使其串行化，必須的一個一個執行。

四、緩存預熱

緩存預熱就是系統上線後，将相關的緩存資料直接加載到緩存系統。

這樣就可以避免在使用者請求的時候，先查詢資料庫，然後再将資料緩存的問題！使用者直接查詢事先被預熱的緩存資料！

1、直接寫個緩存重新整理頁面，上線時手工操作下；

2、資料量不大，可以在項目啟動的時候自動進行加載；

目的就是在系統上線前，将資料加載到緩存中。

以上就是緩存雪崩、預熱、降級等的介紹。

每日分享bat架構+面試+技術幹貨！堅持原創不易，覺得不錯點贊支援，送你【BAT架構80期學習資料合集】，回複【架構】領取。