快取雪崩
簡介：快取同一時間大面積的失效，所以，後面的請求都會落到資料庫上，造成資料庫短時間內承受大量請求而崩掉。
事前：盡量保證整個 redis 集群的高可用性，發現機器宕機盡快補上。選擇合適的記憶體淘汰策略。
事中：本地ehcache快取 + hystrix限流&降級，避免mysql崩掉
事後：利用 redis 持久化機制儲存的資料盡快恢復快取
快取穿透
簡介：一般是黑客故意去請求快取中不存在的資料，導致所有的請求都落到資料庫上，造成資料庫短時間內承受大量請求而崩掉。
解決辦法： 有很多種方法可以有效地解決快取穿透問題，最常見的則是採用布隆過濾器，將所有可能存在的資料雜湊到乙個足夠大的bitmap中，乙個一定不存在的資料會被 這個bitmap攔截掉，從而避免了對底層儲存系統的查詢壓力。另外也有乙個更為簡單粗暴的方法（我們採用的就是這種），如果乙個查詢返回的資料為空（不管是數 據不存在，還是系統故障），我們仍然把這個空結果進行快取，但它的過期時間會很短，最長不超過五分鐘。
Redis快取穿透和快取雪崩
了解過redis的人都知道，在執行讀操作 查詢等 的時候會先從快取中讀取，快取中沒有的話再去資料庫中查詢。如下圖 概念 使用者想要查詢乙個資料，發現redis快取中沒有，也就是快取沒有命中，於是向持久層資料庫查詢。發現也沒有，於是本次查詢失敗。當使用者很多的時候，快取都沒有命中 如秒殺 於是都去請求...
redis快取雪崩和快取穿透
快取雪崩 由於原有的快取過期失效，新的快取還沒有快取進來，有乙隻請求快取請求不到，導致所有請求都跑去了資料庫，導致資料庫io 記憶體和cpu眼裡過大，甚至導致宕機，使得整個系統崩潰。解決思路 1，採用加鎖計數，或者使用合理的佇列數量來避免快取失效時對資料庫造成太大的壓力。這種辦法雖然能緩解資料庫的壓...
Redis的快取穿透 快取擊穿和快取雪崩問題
快取穿透 關注點 要查詢的資料快取中沒有，資料庫中也沒有 情景 就是在使用了快取的基礎上，去查詢乙個快取中沒有，資料庫中也沒有的空資料，也就是壓根不存在的資料 如果被人寫乙個程式去頻繁的呼叫這個查詢空資料的請求，那麼就有可能把資料庫搞崩潰 解決方案 1 快取空物件 第一次查詢快取中沒有，去查詢資料庫...