redis快取雪崩和快取穿透、快取預熱、快取降級
我們可以簡單的理解為：由於原有快取失效，新快取還沒有存入到redis的期間
比方說：我們設定快取時採用了相同的過期時間，在同一時刻出現大面積的快取過期，所有原本應該訪問快取的請求都去查詢資料庫了，而對資料庫cpu和記憶體造成巨大壓力，嚴重的會造成資料庫宕機。從而形成一系列連鎖反應，造成整個系統崩潰。
解決辦法：
加最多的解決方案就是鎖，或者佇列的方式來保證不會有大量的執行緒對資料庫一次性進行讀寫，從而避免失效時大量的併發請求落到底層儲存系統上。還有乙個簡單方案就是快取失效時間分散開，不設定固定的實效時間，採用隨機失效的策略來解決
快取穿透是指使用者查詢資料，在資料庫沒有，自然在快取中也不會有。這樣就導致使用者查詢的時候，在快取中找不到，每次都要去資料庫再查詢一遍，然後返回空，這就相當於進行了兩次無用的查詢。像這樣請求就繞過快取直接查資料庫，這也是經常提的快取命中率問題
解決辦法
最常見的則是採用布隆過濾器，將所有可能存在的資料雜湊到乙個足夠大的bitmap中，乙個一定不存在的資料會被這個bitmap攔截掉，從而避免了對底層儲存系統的查詢壓力。另外也有乙個更為簡單粗暴的方法，如果乙個查詢返回的資料為空，不管是資料不存在，還是系統故障，我們仍然把這個空結果進行快取，但它的過期時間會很短，最長不超過五分鐘。
快取預熱就是系統上線後，將相關的快取資料直接載入到快取系統。這樣就可以避免在使用者請求的時候，先查詢資料庫，然後再將資料快取的問題！使用者直接查詢事先被預熱的快取資料！
操作方式：
1、直接寫個快取重新整理頁面，上線時手工操作下；
2、資料量不大，可以在專案啟動的時候自動進行載入；
然後就是快取更新：
1、定時去清理過期的快取；
2.、當有使用者請求過來時，再判斷這個請求所用到的快取是否過期，過期的話就去底層系統得到新資料並更新快取
當訪問量劇增、服務出現問題，比如響應時間慢或不響應，或者非核心服務影響到核心流程的效能時，仍然需要保證服務還是可用的，即使是有問題的服務。redis可以幫助系統實現資料降級載體，系統可以根據一些關鍵資料進行自動降級，也可以配置開關實現人工降級。降級的最終目的是保證核心服務可用，即使是有損的。
Redis快取穿透和快取雪崩
了解過redis的人都知道，在執行讀操作 查詢等 的時候會先從快取中讀取，快取中沒有的話再去資料庫中查詢。如下圖 概念 使用者想要查詢乙個資料，發現redis快取中沒有，也就是快取沒有命中，於是向持久層資料庫查詢。發現也沒有，於是本次查詢失敗。當使用者很多的時候，快取都沒有命中 如秒殺 於是都去請求...
redis快取雪崩和快取穿透
快取雪崩 由於原有的快取過期失效，新的快取還沒有快取進來，有乙隻請求快取請求不到，導致所有請求都跑去了資料庫，導致資料庫io 記憶體和cpu眼裡過大，甚至導致宕機，使得整個系統崩潰。解決思路 1，採用加鎖計數，或者使用合理的佇列數量來避免快取失效時對資料庫造成太大的壓力。這種辦法雖然能緩解資料庫的壓...
Redis 快取穿透 快取雪崩和快取擊穿
快取穿透，是指查詢乙個資料庫一定不存在的資料。正常的使用快取流程大致是，資料查詢先進行快取查詢，如果key不存在或者key已經過期，再對資料庫進行查詢，並把查詢到的物件，放進快取。如果資料庫查詢物件為空，則不放進快取。流程 引數傳入物件主鍵id 根據key從快取中獲取物件 如果物件不為空，直接返回 ...