造成的原因
1.業務自身**或資料出現問題；
2.一些惡意攻擊、爬蟲造成大量空的命中，此時會對資料庫造成很大壓力。
解決方法
1.設定布隆過濾器，將所有可能存在的資料雜湊到乙個足夠大的bitmap中，乙個一定不存在的資料會被這個bitmap攔截掉，
從避免了對底層儲存系統的查詢壓力。
2. 如果乙個查詢返回的資料為空，不管是資料不存在還是系統故障，我們仍然把這個結果進行快取，但是它的過期時間會很短
最長不超過5分鐘。
因為快取層承載了大量的請求，有效的保護了儲存 層，但是如果快取由於某些原因，整體不能夠提供服務，於是所有的請求，就會到達儲存層，儲存層的呼叫量就會暴增，造成儲存層也會掛掉的情況。快取雪崩的英文解釋是奔逃的野牛，指的是快取層當掉之後，併發流量會像奔騰的野牛一樣，大量後端儲存。
存在這種問題的乙個場景是：當快取伺服器重啟或者大量快取集中在某乙個時間段失效，這樣在失效的時候，大量資料會去直接訪問db，此時給db很大的壓力。
2.解決方法
1.設定redis集群和db集群的高可用，如果redis出現宕機情況，可以立即由別的機器頂替上來。這樣可以防止一部分的風險。
2.使用互斥鎖
在快取失效後，通過加鎖或者佇列來控制讀和寫資料庫的執行緒數量。比如：對某個key只允許乙個執行緒查詢資料和寫快取，其他執行緒等待。單機的話，可以使用synchronized或者lock來解決，如果是分布式環境，可以是用redis的setnx命令來解決。
3.不同的key,可以設定不同的過期時間，讓快取失效的時間點不一致，盡量達到平均分布。
4.永遠不過期
redis中設定永久不過期，這樣就保證了，不會出現熱點問題，也就是物理上不過期。
5.資源保護
使用netflix的hystrix，可以做各種資源的執行緒池隔離，從而保護主線程池。
Redis快取穿透和快取雪崩
了解過redis的人都知道，在執行讀操作 查詢等 的時候會先從快取中讀取，快取中沒有的話再去資料庫中查詢。如下圖 概念 使用者想要查詢乙個資料，發現redis快取中沒有，也就是快取沒有命中，於是向持久層資料庫查詢。發現也沒有，於是本次查詢失敗。當使用者很多的時候，快取都沒有命中 如秒殺 於是都去請求...
redis快取雪崩和快取穿透
快取雪崩 由於原有的快取過期失效，新的快取還沒有快取進來，有乙隻請求快取請求不到，導致所有請求都跑去了資料庫，導致資料庫io 記憶體和cpu眼裡過大，甚至導致宕機，使得整個系統崩潰。解決思路 1，採用加鎖計數，或者使用合理的佇列數量來避免快取失效時對資料庫造成太大的壓力。這種辦法雖然能緩解資料庫的壓...
Redis 快取穿透 快取雪崩和快取擊穿
快取穿透，是指查詢乙個資料庫一定不存在的資料。正常的使用快取流程大致是，資料查詢先進行快取查詢，如果key不存在或者key已經過期，再對資料庫進行查詢，並把查詢到的物件，放進快取。如果資料庫查詢物件為空，則不放進快取。流程 引數傳入物件主鍵id 根據key從快取中獲取物件 如果物件不為空，直接返回 ...