redis快取穿透 雪崩和快取失效的預防和解決

2021-08-28 23:33:16 字數 510 閱讀 7310

對所有可能查詢的引數以hash形式儲存,在控制層先進行校驗,不符合則丟棄。還有最常見的則是採用布隆過濾器,將所有可能存在的資料雜湊到乙個足夠大的bitmap中,乙個一定不存在的資料會被這個bitmap攔截掉,從而避免了對底層儲存系統的查詢壓力。

也可以採用乙個更為簡單粗暴的方法,如果乙個查詢返回的資料為空(不管是數 據不存在,還是系統故障),我們仍然把這個空結果進行快取,但它的過期時間會很短,最長不超過五分鐘。

在快取失效後,通過加鎖或者佇列來控制讀資料庫寫快取的執行緒數量。比如對某個key只允許乙個執行緒查詢資料和寫快取,其他執行緒等待。

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

不同的key,設定不同的過期時間,讓快取失效的時間點盡量均勻

做二級快取,或者雙快取策略。a1為原始快取,a2為拷貝快取,a1失效時,可以訪問a2,a1快取失效時間設定為短期,a2設定為長期。

Redis快取穿透和快取雪崩

了解過redis的人都知道,在執行讀操作 查詢等 的時候會先從快取中讀取,快取中沒有的話再去資料庫中查詢。如下圖 概念 使用者想要查詢乙個資料,發現redis快取中沒有,也就是快取沒有命中,於是向持久層資料庫查詢。發現也沒有,於是本次查詢失敗。當使用者很多的時候,快取都沒有命中 如秒殺 於是都去請求...

redis快取雪崩和快取穿透

快取雪崩 由於原有的快取過期失效,新的快取還沒有快取進來,有乙隻請求快取請求不到,導致所有請求都跑去了資料庫,導致資料庫io 記憶體和cpu眼裡過大,甚至導致宕機,使得整個系統崩潰。解決思路 1,採用加鎖計數,或者使用合理的佇列數量來避免快取失效時對資料庫造成太大的壓力。這種辦法雖然能緩解資料庫的壓...

Redis 快取穿透 快取雪崩和快取擊穿

快取穿透,是指查詢乙個資料庫一定不存在的資料。正常的使用快取流程大致是,資料查詢先進行快取查詢,如果key不存在或者key已經過期,再對資料庫進行查詢,並把查詢到的物件,放進快取。如果資料庫查詢物件為空,則不放進快取。流程 引數傳入物件主鍵id 根據key從快取中獲取物件 如果物件不為空,直接返回 ...