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