緩存雪崩的基于事前+事中+事後三個層次的完美解決方案

相對來說，考慮的比較完善的一套方案，分為事前、事中、事後三個層次去思考再怎麼來應對緩存雪崩的場景

對于解決方案，再次強調一下，這個需要有上下文的，本課程的方案基本上就是基于本課程的緩存架構方案來講解的

通過下面的架構圖，來分析具體的方案内容

#事前解決方案

發生緩存雪崩之前，事情之前，怎麼去避免 redis 徹底挂掉

1. redis本身的高可用性、複制、主從架構，操作主節點，讀寫，資料同步到從節點，一旦主節點挂掉，從節點跟上
2. 雙機房部署，一套 redis cluster，部分機器在一個機房，另一部分機器在另外一個機房

3. 還有一種部署方式，兩套 redis cluster，兩套 redis cluster 之間做一個資料的同步，redis 叢集是可以搭建成樹狀的結構的

   對于這種方式，沒有明白怎麼做資料同步？

   一旦說單個機房出了故障，至少說另外一個機房還能有些 redis 執行個體提供服務

#事中解決方案

redis cluster 已經徹底崩潰了，已經開始大量的通路無法通路到 redis 了

#ehcache 本地緩存

所做的多級緩存架構的作用上了 ，ehcache 的緩存應對零散的 redis 中資料被清除掉的現象，另外一個主要是預防 redis 徹底崩潰

多台機器上部署的緩存服務執行個體的記憶體中，還有一套 ehcache 的緩存，還能支撐一陣

#對 redis 通路的資源隔離

對 redis 通路使用 hystrix 進行隔離，防止自己資源大量阻塞在通路 redis 上

#對源服務通路的限流以及資源隔離

同上，防止自己資源大量阻塞在通路源服務上，同時 hystrix 在資源隔離時也做到了限流

#事後解決方案

1. redis 資料可以恢複，之前講解過各種備份機制，redis 資料備份和恢複，redis 重新啟動起來
2. redis 資料徹底丢失了或者資料過舊，快速緩存預熱，redis 重新啟動起來

由于事中做了限流與隔離，緩存服務不會被打死，通過熔斷政策 和 half-open 政策， 可以自動可以恢複對 redis 的通路，發現 redis 可以通路了，就自動恢複了

#小結

基于 hystrix 的高可用服務這塊技術之後，先講解緩存服務如何設計成高可用的架構

緩存架構應對高并發下的緩存雪崩的解決方案，基于 hystrix 去做緩存服務的保護

要帶着大家去實作的有什麼東西？事前和事後不用了吧，事中 ehcache 本身也做好了

基于 hystrix 對 redis 的通路進行保護，對源服務的通路進行保護，講解 hystrix 的時候， 也說過對源服務的通路怎麼怎麼進行這種高可用的保護

但是站的角度不同，源服務如果自己本身不知道什麼原因出了故障，我們怎麼去保護，調用商品服務的接口大量的報錯、逾時

總的來說就是：限流、資源隔離、降級 保證緩存服務不能死掉，同時快速恢複 redis cluster