阿里一面：關於【緩存穿透、緩存擊穿、緩存雪崩】問題的解決方案

這篇文章，是一位同窗對本身阿里一面的總結，你們能夠參考一下！

1、前言

昨天晚上接到阿里的電面電話，過程當中就問到了關於緩存相關的問題。

雖然之前接觸過，多多少少了解了一些。可是以前本身並無好好記錄這些內容，在真正面試的時候，並無回答得出來。今天記錄一下，長長記性。

在咱們的日常的項目中多多少少都會使用到緩存，由於一些數據咱們沒有必要每次查詢的時候都去查詢到數據庫。

特別是高 QPS 的系統，每次都去查詢數據庫，對於你的數據庫來講將是災難。

今天咱們不牽涉多級緩存的知識，就把系統使用到的緩存方案，不論是一級仍是多級的都統稱爲緩存，主要是爲了講述使用緩存的時候可能會遇到的一些問題以及一些解決辦法。

咱們使用緩存時，咱們的業務系統大概的調用流程以下圖：

當咱們查詢一條數據時，先去查詢緩存，若是緩存有就直接返回，若是沒有就去查詢數據庫，而後返回。這種狀況下就可能會出現一些現象。

2、緩存穿透

2.1 什麼是緩存穿透

正常狀況下，咱們去查詢數據都是存在。

那麼請求去查詢一條壓根兒數據庫中根本就不存在的數據，也就是緩存和數據庫都查詢不到這條數據，可是請求每次都會打到數據庫上面去。

這種查詢不存在數據的現象咱們稱爲緩存穿透。

2.2 穿透帶來的問題

試想一下，若是有黑客會對你的系統進行攻擊，拿一個不存在的id 去查詢數據，會產生大量的請求到數據庫去查詢。可能會致使你的數據庫因爲壓力過大而宕掉。

2.3 解決辦法

2.3.1 緩存空值

之因此會發生穿透，就是由於緩存中沒有存儲這些空數據的key。從而致使每次查詢都到數據庫去了。

那麼咱們就能夠爲這些key對應的值設置爲null 丟到緩存裏面去。後面再出現查詢這個key 的請求的時候，直接返回null 。

這樣，就不用在到數據庫中去走一圈了，可是別忘了設置過時時間。

2.3.2 BloomFilter

BloomFilter 相似於一個hbase set 用來判斷某個元素（key）是否存在於某個集合中。

這種方式在大數據場景應用比較多，好比 Hbase 中使用它去判斷數據是否在磁盤上。還有在爬蟲場景判斷url 是否已經被爬取過。

這種方案能夠加在第一種方案中，在緩存以前在加一層 BloomFilter ，在查詢的時候先去 BloomFilter 去查詢 key 是否存在，若是不存在就直接返回，存在再走查緩存 -> 查 DB。

流程圖以下：

2.4 如何選擇

針對於一些惡意攻擊，攻擊帶過來的大量key 是不存在的，那麼咱們採用第一種方案就會緩存大量不存在key的數據。

此時咱們採用第一種方案就不合適了，咱們徹底能夠先對使用第二種方案進行過濾掉這些key。

針對這種key異常多、請求重複率比較低的數據，咱們就沒有必要進行緩存，使用第二種方案直接過濾掉。

而對於空數據的key有限的，重複率比較高的，咱們則能夠採用第一種方式進行緩存。

3、 緩存擊穿

3.1 什麼是擊穿

緩存擊穿是咱們可能遇到的第二個使用緩存方案可能遇到的問題。

在日常高併發的系統中，大量的請求同時查詢一個 key 時，此時這個key正好失效了，就會致使大量的請求都打到數據庫上面去。這種現象咱們稱爲緩存擊穿。

3.2 會帶來什麼問題

會形成某一時刻數據庫請求量過大，壓力劇增。

3.3 如何解決

上面的現象是多個線程同時去查詢數據庫的這條數據，那麼咱們能夠在第一個查詢數據的請求上使用一個 互斥鎖來鎖住它。

其餘的線程走到這一步拿不到鎖就等着，等第一個線程查詢到了數據，而後作緩存。後面的線程進來發現已經有緩存了，就直接走緩存。

4、緩存雪崩

4.1 什麼是緩存雪崩

緩存雪崩的狀況是說，當某一時刻發生大規模的緩存失效的狀況，好比你的緩存服務宕機了，會有大量的請求進來直接打到DB上面。結果就是DB 稱不住，掛掉。

4.2 解決辦法

4.2.1 事前：

使用集羣緩存，保證緩存服務的高可用

這種方案就是在發生雪崩前對緩存集羣實現高可用，若是是使用 Redis，可使用 主從+哨兵 ，Redis Cluster 來避免 Redis 全盤崩潰的狀況。

4.2.2 事中：

ehcache本地緩存 + Hystrix限流&降級,避免MySQL被打死

使用 ehcache 本地緩存的目的也是考慮在 Redis Cluster 徹底不可用的時候，ehcache 本地緩存還可以支撐一陣。

使用 Hystrix進行限流 & 降級 ，好比一秒來了5000個請求，咱們能夠設置假設只能有一秒 2000個請求能經過這個組件，那麼其餘剩餘的 3000 請求就會走限流邏輯。

而後去調用咱們本身開發的降級組件（降級），好比設置的一些默認值呀之類的。以此來保護最後的 MySQL 不會被大量的請求給打死。

4.2.3 過後：

開啓Redis持久化機制，儘快恢復緩存集羣

一旦重啓，就能從磁盤上自動加載數據恢復內存中的數據。

防止雪崩方案以下圖所示：

5、 解決熱點數據集中失效問題

咱們在設置緩存的時候，通常會給緩存設置一個失效時間，過了這個時間，緩存就失效了。

對於一些熱點的數據來講，當緩存失效之後會存在大量的請求過來，而後打到數據庫去，從而可能致使數據庫崩潰的狀況。

5.1 解決辦法

5.1.1 設置不一樣的失效時間

爲了不這些熱點的數據集中失效，那麼咱們在設置緩存過時時間的時候，咱們讓他們失效的時間錯開。

好比在一個基礎的時間上加上或者減去一個範圍內的隨機值。

5.1.2 互斥鎖

結合上面的擊穿的狀況，在第一個請求去查詢數據庫的時候對他加一個互斥鎖，其他的查詢請求都會被阻塞住，直到鎖被釋放，從而保護數據庫。

可是也是因爲它會阻塞其餘的線程，此時系統吞吐量會降低。須要結合實際的業務去考慮是否要這麼作。