1.1什麼是快取雪崩？
回顧一下我們為什麼要用快取(redis)：
現在有個問題，如果我們的快取掛掉了，這意味著我們的全部請求都跑去資料庫了。
在前面學習我們都知道redis不可能把所有的資料都快取起來(記憶體昂貴且有限)，所以redis需要對資料設定過期時間，並採用的是惰性刪除+定期刪除兩種策略對過期鍵刪除。redis對過期鍵的策略+持久化
如果快取資料設定的過期時間是相同的，並且redis恰好將這部分資料全部刪光了。這就會導致在這段時間內，這些快取同時失效，全部請求到資料庫中。
這就是快取雪崩：
快取雪崩如果發生了，很可能就把我們的資料庫搞垮，導致整個服務癱瘓！
1.2如何解決快取雪崩？
對於「對快取資料設定相同的過期時間，導致某段時間內快取失效，請求全部走資料庫。」這種情況，非常好解決：
對於「redis掛掉了，請求全部走資料庫」這種情況，我們可以有以下的思路：
2.1什麼是快取穿透
比如，我們有一張資料庫表，id都是從1開始的(正數)：
但是可能有黑客想把我的資料庫搞垮，每次請求的id都是負數。這會導致我的快取就沒用了，請求全部都找資料庫去了，但資料庫也沒有這個值啊，所以每次都返回空出去。
快取穿透是指查詢乙個一定不存在的資料。由於快取不命中，並且出於容錯考慮，如果從資料庫查不到資料則不寫入快取，這將導致這個不存在的資料每次請求都要到資料庫去查詢，失去了快取的意義。
這就是快取穿透：
快取穿透如果發生了，也可能把我們的資料庫搞垮，導致整個服務癱瘓！
2.1如何解決快取穿透？
解決快取穿透也有兩種方案：
3.1對於讀操作，流程是這樣的
上面講快取穿透的時候也提到了：如果從資料庫查不到資料則不寫入快取。
一般我們對讀操作的時候有這麼乙個固定的套路：
3.2什麼是快取與資料庫雙寫一致問題？
如果僅僅查詢的話，快取的資料和資料庫的資料是沒問題的。但是，當我們要更新時候呢？各種情況很可能就造成資料庫和快取的資料不一致了。
從理論上說，只要我們設定了鍵的過期時間，我們就能保證快取和資料庫的資料最終是一致的。因為只要快取資料過期了，就會被刪除。隨後讀的時候，因為快取裡沒有，就可以查資料庫的資料，然後將資料庫查出來的資料寫入到快取中。
除了設定過期時間，我們還需要做更多的措施來盡量避免資料庫與快取處於不一致的情況發生。
3.3對於更新操作
一般來說，執行更新操作時，我們會有兩種選擇：
首先，要明確的是，無論我們選擇哪個，我們都希望這兩個操作要麼同時成功，要麼同時失敗。所以，這會演變成乙個分布式事務的問題。
所以，如果原子性被破壞了，可能會有以下的情況：
如果第一步已經失敗了，我們直接返回exception出去就好了，第二步根本不會執行。下面我們具體來分析一下吧。
3.3.1操作快取
操作快取也有兩種方案：
一般我們都是採取刪除快取快取策略的，原因如下：
高併發環境下，無論是先運算元據庫還是後運算元據庫而言，如果加上更新快取，那就更加容易導致資料庫與快取資料不一致問題。(刪除快取直接和簡單很多)
如果每次更新了資料庫，都要更新快取【這裡指的是頻繁更新的場景，這會耗費一定的效能】，倒不如直接刪除掉。等再次讀取時，快取裡沒有，那我到資料庫找，在資料庫找到再寫到快取裡邊(體現懶載入)
基於這兩點，對於快取在更新時而言，都是建議執行刪除操作！
3.3.2先更新資料庫，再刪除快取
正常的情況是這樣的：
如果原子性被破壞了：
如果在高併發的場景下，出現資料庫與快取資料不一致的概率特別低，也不是沒有：
要達成上述情況，還是說一句概率特別低：
因為這個條件需要發生在讀快取時快取失效，而且併發著有乙個寫操作。而實際上資料庫的寫操作會比讀操作慢得多，而且還要鎖表，而讀操作必需在寫操作前進入資料庫操作，而又要晚於寫操作更新快取，所有的這些條件都具備的概率基本並不大。對於這種策略，其實是一種設計模式：cache aside pattern
刪除快取失敗的解決思路：
3.3.3先刪除快取，再更新資料庫
正常情況是這樣的：
如果原子性被破壞了：
看起來是很美好，但是我們在併發場景下分析一下，就知道還是有問題的了：
所以也會導致資料庫和快取不一致的問題。
併發下解決資料庫與快取不一致的思路：
3.4對比兩種策略
我們可以發現，兩種策略各自有優缺點：
3.5其他保障資料一致的方案與資料
可以用databus或者阿里的canal監聽binlog進行更新。
Redis雪崩和Redis穿透
redis雪崩 查詢時redis沒有資料本來先從redis裡面查某個資料 但是redis中這個資料剛好被刪除了，還沒來得及更新 一瞬間很多請求直接進入了mysql進行查詢 而mysql承受不了太大壓力，就會出現雪崩redis穿透 跳過我們預想的資料本來先從redis裡面查某個資料 但是redis中沒...
redis 雪崩，穿透，擊穿
雪崩 同一時間key大面積失效 多出現在定時任務重新整理時 處理方案 1，把每個key的失效時間都加乙個隨機值 2，設定熱點資料永不過期，有更新操作就更新快取 3，如果時集群，將熱點資料均勻分布在不同的redis庫仲 穿透 快取和資料庫仲都沒有的資料時，使用者不斷的發起請求 處理方案 1，在介面層增...
Redis雪崩 穿透 擊穿
1 定義 1.快取穿透是指查詢乙個一定不存在的資料，由於快取不命中，接著查詢資料庫也無法查詢出結果，2.雖然也不會寫入到快取中，但是這將會導致每個查詢都會去請求資料庫，造成快取穿透 2 解決方法 布隆過濾 1.對所有可能查詢的引數以hash形式儲存，在控制層先進行校驗，不符合則丟棄，從而避免了對底層...