在我們的實際業務場景中,Redis 一般和其他資料庫搭配使用,用來減輕後端資料庫的壓力,例如和關係型資料庫MySQL 配合使用。
Redis 會把MySQL 中經常被查詢的數據緩存起來,例如熱點數據,這樣當用戶來訪問的時候,就不需要到MySQL 中去查詢了,而是直接獲取Redis 中的快取數據,從而降低了後端資料庫的讀取壓力。
如果說使用者查詢的資料Redis 沒有,此時使用者的查詢請求就會轉到MySQL 資料庫,當MySQL 將資料傳回給客戶端時,同時會將資料快取到Redis 中,這樣當使用者再次讀取時,就可以直接從Redis 取得資料。流程圖如下所示:
在使用Redis作為快取資料庫時,我們不可避免地會面對三種常見的快取問題
快取穿透
#快取擊穿
快取雪崩
快取穿透是指當使用者查詢某個資料時,Redis 中不存在該數據,也就是快取沒有命中,此時查詢請求就會轉向持久層資料庫MySQL,結果發現MySQL 中也不存在該數據,MySQL 只能傳回一個空對象,代表此次查詢失敗。如果這種類別請求非常多,或是使用者利用這種請求進行惡意攻擊,就會對 MySQL 資料庫造成很大壓力,甚至於崩潰,這種現象就叫做快取穿透。
##當MySQL傳回空物件時, Redis 將該物件快取起來,同時為其設定一個過期時間。 當使用者再次發起相同請求時,就會從快取中拿到一個空物件,使用者的請求被阻斷在了快取層,從而保護了後端資料庫,但是這種做法也存在一些問題,雖然請求進不了MSQL,但是這種策略會佔用Redis 的快取空間。
首先將用戶可能會存取的熱點資料的所有key存儲在布隆過濾器中(也稱為快取預熱),當有一個使用者請求時會先經過布隆過濾器,布隆過濾器會判斷請求的key是否存在,若不存在,那麼該請求將直接被拒絕,否則將繼續執行查詢,先前往快取中查詢,快取沒有的話再前往資料庫中查詢。相較於第一種方法,用布隆過濾器方法更有效率、實用。 其流程示意圖如下:
2.3 解決方案的比較快取預熱是在系統啟動前,提前將相關資料載入到Redis 快取系統中的過程。這樣避免了用戶請求的時再去載入資料。
兩個方案都可以解決快取穿透的問題,但其使用的場景卻不同:
三、快取擊穿3.1 介紹快取空物件:適用於空資料的key數量有限、key重複請求機率較高的場景。
布隆過濾器:適用於空資料的key各不相同、key重複請求機率較低的場景。
3.2 解決方案快取擊穿是指使用者查詢的資料快取中不存在,但是後端資料庫卻存在,這種現像出現原因是一般是由快取中key 過期導致的。例如一個熱點資料 key,它無時無刻都在接受大量的並發訪問,如果某一時刻這個 key 突然失效了,就致使大量的並發請求進入後端資料庫,導致其壓力瞬間增大。這種現象稱為快取擊穿。
設定熱點資料永不過期。
採用分散式鎖定的方法,重新設計快取的使用方式,流程如下:
#上鎖:當我們透過key 去查詢資料時,先查詢緩存,如果沒有,就透過分散式鎖加鎖,第一個取得鎖的進程進入後端資料庫查詢,並將查詢結果緩到Redis 中。
解鎖:當其他行程發現鎖定被某個行程佔用時,就進入等待狀態,直到解鎖後,其餘行程再依序存取被快取的key 。
#永遠不會過期:這個方案由於沒有設定真正的過期時間,實際上已經不存在熱點key 產生的一系列危害,但是會存在資料不一致的情況,同時程式碼複雜度會增大。
互斥鎖:這種方案思路比較簡單,但是有一定的隱患,如果建置快取過程出現問題或時間較長,可能會存在死鎖和執行緒池阻塞的風險,但是這種方法能夠較好的降低後端儲存負載並在一致性上做的比較好。
快取雪崩是指快取中大批量的key 同時過期,而此時數據訪問量又非常大,從而導致後端資料庫壓力突然暴增,甚至會掛掉,這種現象稱為快取雪崩。它和緩存擊穿不同,緩存擊穿是在並發量特別大時,某一個熱點 key 突然過期,而緩存雪崩則是大量的 key 同時過期,因此它們根本不是一個量級。
##為了減少大量按鍵同時過期帶來的快取擊穿和雪崩問題,可以採用熱點資料永不過期的策略,這與快取雪崩有相似之處。此外,為了避免key同時過期,可以為其設定隨機過期時間。
#一台Redis可能會因為雪崩而掛掉,那麼可以多增設幾台Redis,搭建集群,如果一台掛掉之後,其他的還可以繼續工作。
#
以上是Redis快取問題的範例分析的詳細內容。更多資訊請關注PHP中文網其他相關文章!