Redis快取穿透和快取雪崩

2021-10-04 16:36:39 字數 2477 閱讀 1383

了解過redis的人都知道,在執行讀操作(查詢等)的時候會先從快取中讀取,快取中沒有的話再去資料庫中查詢。

如下圖:

概念

使用者想要查詢乙個資料,發現redis快取中沒有,也就是快取沒有命中,於是向持久層資料庫查詢。發現也沒有,於是本次查詢失敗。當使用者很多的時候,快取都沒有命中(如秒殺),於是都去請求了持久層資料庫。這會給持久層資料庫造成很大的壓力,這時候就相當於出現了快取穿透。

正常快取處理流程:

快取穿透情況處理流程:

解決方案

布隆過濾器布隆過濾器是一種資料結構,對所有可能查詢的引數以hash形式儲存,在控制層先進行檢驗,不符合則丟棄,從而避免了對底層儲存系統的查詢壓力。

快取空物件

當儲存層不命中後,即使返回的空物件也將其快取起來,同時會設定乙個過期時間,之後再訪問這個資料將會從快取中獲取,保護了後端資料來源。

但是這種方法會存在兩個問題:

1、如果空值能夠被快取起來,這就意味著快取需要更多的空間儲存更多的鍵,因為這當中可能會有很多的空值的鍵;

2、即使對空值設定了過期時間,還是會存在快取層和儲存層的資料會有一段時間視窗的不一致,這對於需要保持一致性的業務會有影響。

概述

這裡需要注意和快取穿透的區別,快取擊穿,是指乙個key非常熱點,在不停的扛著大併發,大併發集中對這乙個點進行乙個訪問,當這個key在失效的瞬間,持續的大併發就穿破快取,直接請求資料庫,就像在乙個屏障上鑿開了乙個洞。

當某個key在過期的瞬間,有大量的請求併發訪問,這類資料一般更是熱點資料,由於快取過期,會同時訪問資料庫來查詢最新資料,並且回寫快取,會導致資料庫瞬間壓力過大。

解決方案

設定熱點資料永不過期從快取層面來看,沒有設定過期時間,所以不會出現熱點key過期後產生的問題。

加互斥鎖

分布式鎖:使用分布式鎖,保證對於每個key同時只有乙個執行緒去查詢後端服務,其他執行緒沒有獲得分布式鎖的許可權,因此只需要等待即可。這種方式將高併發的壓力轉移到了分布式鎖,因此對分布式鎖的考驗很大。

概念

快取雪崩,是指在乙個時間段,快取集中過期失效。redis宕機。

產生雪崩的原因之一,比如在寫本文的時候,馬上就要到雙十一零點,很快就會迎來一波搶購,這波商品時間比較集中的放入了快取,假設快取乙個小時,那麼到了凌晨一點的時候,這批商品的快取就過期了,而對這批商品的訪問查詢,都落到了資料庫上,對於資料庫而言,就會產生週期性的壓力波峰。於是所有的請求都會達到儲存層,儲存層的呼叫量會暴增,造成儲存曾也會掛掉的情況。

其中集中過期,倒不是非常致命,比較致命的快取雪崩,是快取伺服器某個節點宕機或斷網。因為自然形成的雪崩,一定是在某個時間段集中建立快取,這個時候,資料庫也是可以頂住壓力的。無非就是對資料庫產生週期性的壓力而已。而快取服務節點的宕機。對資料庫伺服器造成的壓力是不可預知的,很有可能瞬間就把資料庫壓垮。

解決方案

(1)redis高可用這個思想的含義是,既然redis有可能掛掉,那我多增設幾台redis,這樣一台掛掉之後其他的還可以繼續工作,其實就是搭建的集群。

(2)限流降級

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

(3)資料預熱

資料加熱的含義就是在正式部署之前,我先把可能的資料先預先訪問一遍,這樣部分可能大量訪問的資料就會載入到快取中。在即將發生大併發訪問前手動觸發載入快取不同的key,設定不同的過期時間,讓快取失效的時間點盡量均勻。

先把可能的資料先預先訪問一遍,這樣部分可能大量訪問的資料就會載入到快取中。在即將發生大併發訪問前手動觸發載入快取不同的key,設定不同的過期時間,讓快取失效的時間點盡量均勻。

redis快取雪崩和快取穿透

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

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

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

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

查詢資料庫中一定不存在的資料,使用者發出查詢請求,根據引數 主鍵id 首先根據key去查詢redis,發現為空,接著查詢資料庫發現沒有結果,然後不會往redis中存入任何資料,接下來所有的請求都會往復進行,都會訪問資料庫,造成資料庫壓力。解決快取穿透,可以在第一次查詢資料庫時,如果返回空,則在red...