再也不怕，緩存雪崩、擊穿、穿透！

用戶的數據一般都是存儲於數據庫，數據庫的數據是落在磁盤上的，磁盤的讀寫速度可以說是計算機裏最慢的硬件了。

因爲 Redis 是內存數據庫，我們可以將數據庫的數據緩存在 Redis 裏，相當於數據緩存在內存，內存的讀寫速度比硬盤快好幾個數量級，這樣大大提高了系統性能。

引入了緩存層，就會有緩存異常的三個問題，分別是緩存雪崩、緩存擊穿、緩存穿透。

這三個問題也是面試中很常考察的問題，我們不光要清楚地知道它們是怎麼發生，還需要知道如何解決它們。

話不多說，發車！

緩存雪崩

通常我們爲了保證緩存中的數據與數據庫中的數據一致性，會給 Redis 裏的數據設置過期時間，當緩存數據過期後，用戶訪問的數據如果不在緩存裏，業務系統需要重新生成緩存，因此就會訪問數據庫，並將數據更新到 Redis 裏，這樣後續請求都可以直接命中緩存。

那麼，當大量緩存數據在同一時間過期（失效）或者 Redis 故障宕機時，如果此時有大量的用戶請求，都無法在 Redis 中處理，於是全部請求都直接訪問數據庫，從而導致數據庫的壓力驟增，嚴重的會造成數據庫宕機，從而形成一系列連鎖反應，造成整個系統崩潰，這就是緩存雪崩的問題。

可以看到，發生緩存雪崩有兩個原因：

不同的誘因，應對的策略也會不同。

大量數據同時過期

針對大量數據同時過期而引發的緩存雪崩問題，常見的應對方法有下面這幾種：

1. 均勻設置過期時間

如果要給緩存數據設置過期時間，應該避免將大量的數據設置成同一個過期時間。我們可以在對緩存數據設置過期時間時，給這些數據的過期時間加上一個隨機數，這樣就保證數據不會在同一時間過期。

2. 互斥鎖

當業務線程在處理用戶請求時，如果發現訪問的數據不在 Redis 裏，就加個互斥鎖，保證同一時間內只有一個請求來構建緩存（從數據庫讀取數據，再將數據更新到 Redis 裏），當緩存構建完成後，再釋放鎖。未能獲取互斥鎖的請求，要麼等待鎖釋放後重新讀取緩存，要麼就返回空值或者默認值。

我們對緩存數據可以使用兩個 key，一個是主 key，會設置過期時間，一個是備 key，不會設置過期，它們只是 key 不一樣，但是 value 值是一樣的，相當於給緩存數據做了個副本。

當業務線程訪問不到「主 key 」的緩存數據時，就直接返回「備 key 」的緩存數據，然後在更新緩存的時候，同時更新「主 key 」和「備 key 」的數據。

4. 後臺更新緩存

業務線程不再負責更新緩存，緩存也不設置有效期，而是讓緩存 “永久有效”，並將更新緩存的工作交由後臺線程定時更新。

事實上，緩存數據不設置有效期，並不是意味着數據一直能在內存裏，因爲當系統內存緊張的時候，有些緩存數據會被 “淘汰”，而在緩存被 “淘汰” 到下一次後臺定時更新緩存的這段時間內，業務線程讀取緩存失敗就返回空值，業務的視角就以爲是數據丟失了。

解決上面的問題的方式有兩種。

第一種方式，後臺線程不僅負責定時更新緩存，而且也負責頻繁地檢測緩存是否有效，檢測到緩存失效了，原因可能是系統緊張而被淘汰的，於是就要馬上從數據庫讀取數據，並更新到緩存。

這種方式的檢測時間間隔不能太長，太長也導致用戶獲取的數據是一個空值而不是真正的數據，所以檢測的間隔最好是毫秒級的，但是總歸是有個間隔時間，用戶體驗一般。

第二種方式，在業務線程發現緩存數據失效後（緩存數據被淘汰），通過消息隊列發送一條消息通知後臺線程更新緩存，後臺線程收到消息後，在更新緩存前可以判斷緩存是否存在，存在就不執行更新緩存操作；不存在就讀取數據庫數據，並將數據加載到緩存。這種方式相比第一種方式緩存的更新會更及時，用戶體驗也比較好。

在業務剛上線的時候，我們最好提前把數據緩起來，而不是等待用戶訪問纔來觸發緩存構建，這就是所謂的緩存預熱，後臺更新緩存的機制剛好也適合幹這個事情。

Redis 故障宕機

針對 Redis 故障宕機而引發的緩存雪崩問題，常見的應對方法有下面這幾種：

1. 服務熔斷或請求限流機制

因爲 Redis 故障宕機而導致緩存雪崩問題時，我們可以啓動服務熔斷機制，暫停業務應用對緩存服務的訪問，直接返回錯誤，不用再繼續訪問數據庫，從而降低對數據庫的訪問壓力，保證數據庫系統的正常運行，然後等到 Redis 恢復正常後，再允許業務應用訪問緩存服務。

服務熔斷機制是保護數據庫的正常允許，但是暫停了業務應用訪問緩存服系統，全部業務都無法正常工作

爲了減少對業務的影響，我們可以啓用請求限流機制，只將少部分請求發送到數據庫進行處理，再多的請求就在入口直接拒絕服務，等到 Redis 恢復正常並把緩存預熱完後，再解除請求限流的機制。

2. 構建 Redis 緩存高可靠集羣

服務熔斷或請求限流機制是緩存雪崩發生後的應對方案，我們最好通過主從節點的方式構建 Redis 緩存高可靠集羣。

如果 Redis 緩存的主節點故障宕機，從節點可以切換成爲主節點，繼續提供緩存服務，避免了由於 Redis 故障宕機而導致的緩存雪崩問題。

緩存擊穿

我們的業務通常會有幾個數據會被頻繁地訪問，比如秒殺活動，這類被頻地訪問的數據被稱爲熱點數據。

可以發現緩存擊穿跟緩存雪崩很相似，你可以認爲緩存擊穿是緩存雪崩的一個子集。

應對緩存擊穿可以採取前面說到兩種方案：

緩存穿透

當發生緩存雪崩或擊穿時，數據庫中還是保存了應用要訪問的數據，一旦緩存恢復相對應的數據，就可以減輕數據庫的壓力，而緩存穿透就不一樣了。

當用戶訪問的數據，既不在緩存中，也不在數據庫中，導致請求在訪問緩存時，發現緩存缺失，再去訪問數據庫時，發現數據庫中也沒有要訪問的數據，沒辦法構建緩存數據，來服務後續的請求。那麼當有大量這樣的請求到來時，數據庫的壓力驟增，這就是緩存穿透的問題。

緩存穿透的發生一般有這兩種情況：

應對緩存穿透的方案，常見的方案有三種。

第一種方案，非法請求的限制

當有大量惡意請求訪問不存在的數據的時候，也會發生緩存穿透，因此在 API 入口處我們要判斷求請求參數是否合理，請求參數是否含有非法值、請求字段是否存在，如果判斷出是惡意請求就直接返回錯誤，避免進一步訪問緩存和數據庫。

第二種方案，緩存空值或者默認值

當我們線上業務發現緩存穿透的現象時，可以針對查詢的數據，在緩存中設置一個空值或者默認值，這樣後續請求就可以從緩存中讀取到空值或者默認值，返回給應用，而不會繼續查詢數據庫。

第三種方案，使用布隆過濾器快速判斷數據是否存在，避免通過查詢數據庫來判斷數據是否存在。

我們可以在寫入數據庫數據時，使用布隆過濾器做個標記，然後在用戶請求到來時，業務線程確認緩存失效後，可以通過查詢布隆過濾器快速判斷數據是否存在，如果不存在，就不用通過查詢數據庫來判斷數據是否存在。

即使發生了緩存穿透，大量請求只會查詢 Redis 和布隆過濾器，而不會查詢數據庫，保證了數據庫能正常運行，Redis 自身也是支持布隆過濾器的。

那問題來了，布隆過濾器是如何工作的呢？接下來，我介紹下。

布隆過濾器由「初始值都爲 0 的位圖數組」和「 N 個哈希函數」兩部分組成。當我們在寫入數據庫數據時，在布隆過濾器裏做個標記，這樣下次查詢數據是否在數據庫時，只需要查詢布隆過濾器，如果查詢到數據沒有被標記，說明不在數據庫中。

布隆過濾器會通過 3 個操作完成標記：

舉個例子，假設有一個位圖數組長度爲 8，哈希函數 3 個的布隆過濾器。

在數據庫寫入數據 x 後，把數據 x 標記在布隆過濾器時，數據 x 會被 3 個哈希函數分別計算出 3 個哈希值，然後在對這 3 個哈希值對 8 取模，假設取模的結果爲 1、4、6，然後把位圖數組的第 1、4、6 位置的值設置爲 1。當應用要查詢數據 x 是否數據庫時，通過布隆過濾器只要查到位圖數組的第 1、4、6 位置的值是否全爲 1，只要有一個爲 0，就認爲數據 x 不在數據庫中。

布隆過濾器由於是基於哈希函數實現查找的，高效查找的同時存在哈希衝突的可能性，比如數據 x 和數據 y 可能都落在第 1、4、6 位置，而事實上，可能數據庫中並不存在數據 y，存在誤判的情況。

所以，查詢布隆過濾器說數據存在，並不一定證明數據庫中存在這個數據，但是查詢到數據不存在，數據庫中一定就不存在這個數據。

總結

緩存異常會面臨的三個問題：緩存雪崩、擊穿和穿透。

其中，緩存雪崩和緩存擊穿主要原因是數據不在緩存中，而導致大量請求訪問了數據庫，數據庫壓力驟增，容易引發一系列連鎖反應，導致系統奔潰。不過，一旦數據被重新加載回緩存，應用又可以從緩存快速讀取數據，不再繼續訪問數據庫，數據庫的壓力也會瞬間降下來。因此，緩存雪崩和緩存擊穿應對的方案比較類似。

而緩存穿透主要原因是數據既不在緩存也不在數據庫中。因此，緩存穿透與緩存雪崩、擊穿應對的方案不太一樣。

我這裏整理了表格，你可以從下面這張表格很好的知道緩存雪崩、擊穿和穿透的區別以及應對方案。

參考資料

1.《極客時間：Redis 核心技術與實戰》

  1. https://github.com/doocs/advanced-java/blob/main/docs/high-concurrency/redis-caching-avalanche-and-caching-penetration.md

  2. https://medium.com/@mena.meseha/3-major-problems-and-solutions-in-the-cache-world-155ecae41d4f

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/sE8xhHUc5qhzeaRga_VFeQ

猜你喜歡