1、擊穿: 指的是單個key在快取中查不到，去資料庫查詢，這樣如果資料量不大或者併發不大的話是沒有什麼問題的。
如果資料庫資料量大並且是高併發的情況下那麼就可能會造成資料庫壓力過大而崩潰。
注意: 這裡指的是單個key發生高併發!!!
解決方案:
通過synchronized+雙重檢查機制：某個key只讓乙個執行緒查詢，阻塞其它執行緒
在同步塊中，繼續判斷檢查，保證不存在，才去查db。
例如:
private static volaite object lockhelp=new object();
public string getvalue(string key)
}}
return value;
}
設定value永不過期
這種方式可以說是最可靠的，最安全的但是佔空間，記憶體消耗大，並且不能保持資料最新 這個需要根據具體的業務邏輯來做 。
個人覺得如果要保持資料最新不放這麼試試，僅供參考：
起個定時任務或者利用timertask 做定時，每個一段時間多這些值進行資料庫查詢更新一次快取，當然前提時不會給資料庫造成壓力過大(這個很重要)
2、穿透
一般是出現這種情況是因為惡意頻繁查詢才會對系統造成很大的問題: key快取並且資料庫不存在，所以每次查詢都會查詢資料庫從而導致資料庫崩潰。
解決方案:
使用布隆過濾器: 熱點資料等場景(具體看使用場景)
3、雪崩
雪崩指的是多個key查詢並且出現高併發，快取中失效或者查不到，然後都去db查詢，從而導致db壓力突然飆公升，從而崩潰。
出現原因:
1）key同時失效
2）redis本身崩潰了
方案:在快取失效後，通過加鎖或者佇列來控制讀資料庫寫快取的執行緒數量。比如對某個key只允許乙個執行緒查詢資料和寫快取，其他執行緒等待。(跟擊穿的第乙個方案類似，但是這樣是避免不了其它key去查資料庫，只能減少查詢的次數)
可以通過快取reload機制，預先去更新快取，再即將發生大併發訪問前手動觸發載入快取。
不同的key，設定不同的過期時間，具體值可以根據業務決定，讓快取失效的時間點盡量均勻。
做二級快取，或者雙快取策略。a1為原始快取，a2為拷貝快取，a1失效時，可以訪問a2，a1快取失效時間設定為短期，a2設定為長期。(這種方式複雜點)
redis雪崩 擊穿 穿透
redis快取 快取流程 使用者訪問前台 前台訪問redis，若redis有使用者要訪問的資料就直接返回 如果沒有就訪問資料庫，如果查到了就把資料同步到redis，並返回給使用者 快取雪崩 場景，雙十一的時候 將很多資料放到redis進行快取，並設定快取的失效時間為三小時，當快取時間到達的一瞬間，大...
redis擊穿，穿透，雪崩以及解決方案
1 擊穿 指的是單個key在快取中查不到，去資料庫查詢，這樣如果資料量不大或者併發不大的話是沒有什麼問題的。如果資料庫資料量大並且是高併發的情況下那麼就可能會造成資料庫壓力過大而崩潰 注意 這裡指的是單個key發生高併發 解決方案 1 通過synchronized 雙重檢查機制 某個key只讓乙個執...
redis 快取擊穿 穿透 雪崩
一般的快取系統，都是按照key去快取查詢，如果不存在對應的value，就去後端系統查詢 比如db 一些惡意的請求會故意查詢不存在的key,請求量很大，就會對後端系統造成很大的壓力。這就叫做快取穿透。如何避免？1 對查詢結果為空的情況也進行快取，這樣，再次訪問時，快取層會直接返回空值。快取時間設定短一...