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