redis擊穿，穿透，雪崩以及解決方案

1 擊穿: 指的是單個key在快取中查不到，去資料庫查詢，這樣如果資料量不大或者併發不大的話是沒有什麼問題的。

如果資料庫資料量大並且是高併發的情況下那麼就可能會造成資料庫壓力過大而崩潰

注意: 這裡指的是單個key發生高併發!!!

解決方案:

1) 通過synchronized+雙重檢查機制：某個key只讓乙個執行緒查詢，阻塞其它線程

在同步塊中，繼續判斷檢查，保證不存在，才去查db。

例如:

private static volaite object lockhelp=new object();

public string getvalue(string key) else

} else

缺點:1. **複雜度增大

2. 存在死鎖的風險

2 雪崩

雪崩指的是多個key查詢並且出現高併發，快取中失效或者查不到，然後都去db查詢，從而導致db壓力突然飆公升，從而崩潰。

出現原因: 1 key同時失效

2 redis本身崩潰了

方案:在快取失效後，通過加鎖或者佇列來控制讀資料庫寫快取的執行緒數量。比如對某個key只允許乙個執行緒查詢資料和寫快取，其他執行緒等待。(跟擊穿的第乙個方案類似，但是這樣是避免不了其它key去查資料庫，只能減少查詢的次數)

可以通過快取reload機制，預先去更新快取，再即將發生大併發訪問前手動觸發載入快取

不同的key，設定不同的過期時間，具體值可以根據業務決定，讓快取失效的時間點盡量均勻

做二級快取，或者雙快取策略。a1為原始快取，a2為拷貝快取，a1失效時，可以訪問a2，a1快取失效時間設定為短期，a2設定為長期。(這種方式複雜點)

3 擊透

一般是出現這種情況是因為惡意頻繁查詢才會對系統造成很大的問題: key快取並且資料庫不存在，所以每次查詢都會查詢資料庫從而導致資料庫崩潰。

解決方案:

1) 使用布隆過濾器: 熱點資料等場景(具體看使用場景)

布隆過濾器是什麼？

布隆過濾器可以理解為乙個不怎麼精確的 set 結構，當你使用它的 contains 方法判斷某個物件是否存在時，它可能會誤判。但是布隆過濾器也不是特別不精確，只要引數設定的合理，它的精確度可以控制的相對足夠精確，只會有小小的誤判概率。

當布隆過濾器說某個值存在時，這個值可能不存在；當它說不存在時，那就肯定不存在。打個比方，當它說不認識你時，肯定就不認識；當它說見過你時，可能根本就沒見過面，不過因為你的臉跟它認識的人中某臉比較相似 (某些熟臉的係數組合)，所以誤判以前見過你。

缺點: 1 會存在一定的誤判率

2 對新增加的資料無法進行布隆過濾

3 資料的key不會頻繁的更改

google 的 gauva 中有布隆過濾的實現

bloomfilter的關鍵在於hash演算法的設定和bit陣列的大小確定，通過權衡得到乙個錯誤概率可以接受的結果。

我們設定的容錯率越小那麼過濾函式也就多，分配的空間也就越大(存放bits)，那麼誤判率也就越小。

2 將擊透的key快取起來，但是時間不能太長，下次進來是直接返回不存在，但是這種情況無法過濾掉動態的key，就是說每次請求進來都是不同額key，這樣還是會造成這個問題