一、什么是緩存雪崩
從下圖可以很清晰出什么是緩存雪崩：
1. 由于Cache層承載著大量請求，有效的保護了Storage層(通常認為此層抗壓能力稍弱)，所以Storage的調(diào)用量實際很低，所以它很爽。
2. 但是，如果Cache層由于某些原因(宕機、cache服務(wù)掛了或者不響應(yīng)了)整體crash掉了，也就意味著所有的請求都會達到Storage層，所有Storage的調(diào)用量會暴增，所以它有點扛不住了，甚至也會掛掉 
雪崩問題在國外叫做：stampeding herd(奔逃的野牛)，指的的cache crash后，流量會像奔逃的野牛一樣，打向后端
二、 緩存雪崩的危害
雪崩的危害顯而易見，通常來講可能很久以前storage已經(jīng)扛不住大量請求了，于是加了cache層，所以雪崩會使得storage壓力山大，甚至是掛掉。
三、如何預(yù)防緩存雪崩
1. 保證Cache服務(wù)高可用性：
和飛機都有多個引擎一樣，如果我們的cache也是高可用的，即使個別實例掛掉了，影響不會很大（主從切換或者可能會有部分流量到了后端），實現(xiàn)自動化運維。例如：
memcache的一致性hash：
redis的sentinel和cluster機制：
有關(guān)memcache和redis的高可用方案，之后會有文章進行介紹。
2. 依賴隔離組件為后端限流：
其實無論是cache或者是mysql, hbase, 甚至別人的API，都會出現(xiàn)問題，我們可以將這些視同為資源，作為并發(fā)量較大的系統(tǒng)，假如有一個資源不可訪問了，即使設(shè)置了超時時間，依然會hang住所有線程，造成其他資源和接口也不可以訪問。
相信大家一定遇到過這樣的頁面：這些應(yīng)該就是淘寶的降級策略。
降級在高并發(fā)系統(tǒng)中是非常正常的：比如推薦服務(wù)中，很多都是個性化的需求，假如個性化需求不能提供服務(wù)了，可以降級補充熱點數(shù)據(jù)，不至于造成前端頁面是個大空白（開了天窗了）
在實際項目中，我們對重要的資源都進行隔離，比如hbase, elasticsearch, zookeeper, redis，別人的api(可能是http, rpc)，讓每種資源都單獨運行在自己的線程池中，即使資源出現(xiàn)了問題，對其他服務(wù)沒有影響。
但是線程池如何管理，比如如何關(guān)閉資源池，開啟資源池，資源池閥值管理，這些做起來還是相當麻煩的，幸好netfilx公司提供了一個很牛逼的工具：hystrix，可以做各種資源的線程池隔離。
有關(guān)hystrix的詳細介紹可以參考：http://hot66hot.iteye.com/blog/2155036
hystrix附圖：
3. 提前演練：
在項目上線前，通過演練，觀察cache crash后，整體系統(tǒng)和storage的負載, 提前做好預(yù)案。
