產生雪崩的原因：
緩存雪崩通俗簡單的理解就是：由于原有緩存失效（或者數據未加載到緩存中），新緩存未到期間（緩存正常從Redis中獲取，如下圖）所有原本應該訪問緩存的請求都去查詢數據庫了，而對數據庫CPU和內存造成巨大壓力，嚴重的會造成數據庫宕機，造成系統的崩潰。
基本解決思路如下：
? 第一，大多數系統設計者考慮用加鎖或者隊列的方式保證來保證不會有大量的線程對數據庫一次性進行讀寫，避免緩存失效時對數據庫造成太大的壓力，雖然能夠在一定的程度上緩解了數據庫的壓力但是與此同時又降低了系統的吞吐量。
?第二，分析用戶的行為，盡量讓緩存失效的時間均勻分布。
?第三，如果是因為某臺緩存服務器宕機，可以考慮做主備，比如：redis主備，但是雙緩存涉及到更新事務的問題，update可能讀到臟數據，需要好好解決。
Redis雪崩效應的解決方案：
1、可以使用分布式鎖，單機版的話本地鎖
2、消息中間件方式
3、一級和二級緩存Redis+Ehchache
4、均攤分配Redis的key的失效時間
解釋：
?1、? 當突然有大量請求到數據庫服務器時候，進行請求限制。使用所的機制，保證只有一個線程（請求）操作。否則進行排隊等待（集群分布式鎖，單機本地鎖）。減少服務器吞吐量，效率低。
?加入鎖！
保證只能有一個線程進入? 實際上只能有一個請求在執行查詢操作
也可以在此處進行使用限流的策略~
2、使用消息中間件解決
這種方案是最靠譜的方案！
消息中間件可以解決高并發！！！
如果大量的請求進行訪問時候，Redis沒有值的情況，會將查詢的結果存放在消息中間件中（利用了MQ異步步特性）
3、做二級緩存，A1為原始緩存，A2為拷貝緩存，A1失效時，可以訪問A2，A1緩存失效時間設置為短期，A2設置為長期（此點為補充）
4、不同的key，設置不同的過期時間，讓緩存失效的時間點盡量均勻。
更多Redis相關知識，請訪問Redis使用教程欄目！
