緩存雪崩
緩存雪崩，是指在某一個時間段，緩存集中過期失效。
產生雪崩的原因之一，比如在寫本文的時候，馬上就要到雙十二零點，很快就會迎來一波搶購，這波商品時間比較集中的放入了緩存，假設緩存一個小時。那么到了凌晨一點鍾的時候，這批商品的緩存就都過期了。而對這批商品的訪問查詢，都落到了數據庫上，對於數據庫而言，就會產生周期性的壓力波峰。
解決思路：
第一，大多數考慮用加鎖或者隊列的方式保證來保證不會有大量的線程對數據庫一次性進行讀寫，避免緩存失效時對數據庫造成太大的壓力，雖然能夠在一定的程度上緩解了數據庫的壓力但是與此同時又降低了系統的吞吐量。
第二，分析用戶的行為，盡量讓緩存失效的時間均勻分布。
第三，如果是因為某台緩存服務器宕機，可以考慮做主備，比如：redis主備，但是雙緩存涉及到更新事務的問題，update可能讀到臟數據，需要好好解決。
其實集中過期，倒不是非常致命，比較致命的緩存雪崩，是緩存服務器某個節點宕機或斷網。因為自然形成的緩存雪崩，一定是在某個時間段集中創建緩存，那么那個時候數據庫能頂住壓力，這個時候，數據庫也是可以頂住壓力的。無非就是對數據庫產生周期性的壓力而已。但是緩存服務節點的宕機，對數據庫服務器造成的壓力是不可預知的，很有可能瞬間就把數據庫壓垮。
緩存失效的時候如下圖：
兩種實際方法：
1. 並發量不是特別多的時候，使用最多的解決方案是加鎖排隊。
加鎖排隊只是為了減輕數據庫的壓力，並沒有提高系統吞吐量。假設在高並發下，緩存重建期間key是鎖着的，這是過來1000個請求999個都在阻塞的。同樣會導致用戶等待超時，這是個治標不治本的方法！
注意：加鎖排隊的解決方式分布式環境的並發問題，有可能還要解決分布式鎖的問題；線程還會被阻塞，用戶體驗很差！因此，在真正的高並發場景下很少使用！
2.還有一個解決辦法解決方案是：給每一個緩存數據增加相應的緩存標記，記錄緩存的是否失效，如果緩存標記失效，則更新數據緩存。
解釋說明：
緩存標記：記錄緩存數據是否過期，如果過期會觸發通知另外的線程在后台去更新實際key的緩存；
緩存數據：它的過期時間比緩存標記的時間延長1倍，例：標記緩存時間30分鍾，數據緩存設置為60分鍾。 這樣，當緩存標記key過期后，實際緩存還能把舊數據返回給調用端，直到另外的線程在后台更新完成后，才會返回新緩存。
3. 比如做電商項目的時候，一般是采取不同分類商品，緩存不同周期。在同一分類中的商品，加上一個隨機因子。這樣能盡可能分散緩存過期時間，而且，熱門類目的商品緩存時間長一些，冷門類目的商品緩存時間短一些，也能節省緩存服務的資源。
關於緩存崩潰的解決方法，這里提出了三種方案：使用鎖或隊列、設置過期標志更新緩存、為key設置不同的緩存失效時間，還有一各被稱為“二級緩存”的解決方法，有興趣的讀者可以自行研究。