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

別人用手機刷新聞、刷段子，你用手機刷知識。你會的越多，成功率就越高。

本篇分享大型網站高併發架構設計是如何解決Redis雪崩、穿透、併發等5大難題的，如下，enjoy~

緩存雪崩

數據未加載到緩存中，或者緩存同一時間大面積的失效，從而致使全部請求都去查數據庫，致使數據庫CPU和內存負載太高，甚至宕機。

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

一、redis集羣大面積故障

二、緩存失效，但依然大量請求訪問緩存服務redis

三、redis大量失效後，大量請求轉向到mysql數據庫

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

五、因爲大量的應用服務依賴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操做放在隊列中使其串行化，必須的一個一個執行。

緩存預熱

緩存預熱就是系統上線後，將相關的緩存數據直接加載到緩存系統。

這樣就能夠避免在用戶請求的時候，先查詢數據庫，而後再將數據緩存的問題！用戶直接查詢事先被預熱的緩存數據！

解決思路：

一、直接寫個緩存刷新頁面，上線時手工操做下；

二、數據量不大，能夠在項目啓動的時候自動進行加載；

目的就是在系統上線前，將數據加載到緩存中。

以上就是緩存雪崩、預熱、降級等的介紹，更多總體從服務器雪崩的角度，參考個人往期文章：阿里P8架構師談：什麼是緩存雪崩？服務器雪崩的場景與解決方案

以爲不錯請點贊支持，歡迎留言或進個人我的羣855801563領取【架構資料專題目合集90期】、【BATJTMD大廠JAVA面試真題1000+】，本羣專用於學習交流技術、分享面試機會，拒絕廣告，我也會在羣內不按期答題、探討。