老司機帶你玩轉面試（2）：Redis 過時策略以及緩存雪崩、擊穿、穿透

前文回顧

建議前一篇文章沒看過的同窗先看下前面的文章：

「老司機帶你玩轉面試（1）：緩存中間件 Redis 基礎知識以及數據持久化」

過時策略

Redis 的過時策略都有哪些？

在聊這個問題以前，必定要明確的一件事情是，如非必要，任何進入緩存的數據都應該設置過時時間，由於內存的大小是有限的，一臺機器可能就那麼幾十個 G ，你不能拿內存和硬盤比，一臺機器硬盤幾個 T 都是灑灑水，只要想裝，幾十個 T 都裝得下，關鍵還不貴。

Redis 設置刪除策略，主要有兩種思路，一種是按期刪除，另外一種是惰性刪除。

按期刪除：

設定一個時間，在 Redis 中默認是每隔 100ms 就隨機抽取一些設置了過時時間的 key，檢查其是否過時，若是過時就刪除。

注意這裏是隨機抽取一些設置了過時時間的 key ，而是掃描全部，試想這樣一個場景，若是我有 100w 個設置了過時時間的 key ，若是每次都所有掃描一遍，基本上 Redis 就死了， CPU 的負載會很是的高，所有都消耗在了檢查過時 key 上面。

惰性刪除：

惰性刪除的意思就是當 key 過時後，不作刪除動做，等到下次使用的時候，發現 key 已通過期，這時不在返回這個 key 對應的 value ，直接將這個 key 刪除掉。

這種方式有一個致命的弱點，就是會有不少過時的 key-value 明明已經到了過時時間，缺還在內存中佔着使用空間，大大下降了內存使用效率。

因此 Redis 的過時策略是：按期刪除 + 惰性刪除。

實際上簡單的按期刪除 + 惰性刪除仍是會存在問題，按期刪除可能會致使不少過時 key 到了時間並無被刪除掉，而後咱們也沒有及時的去作檢查，也沒有作惰性刪除，此時的結果就是大量過時 key 堆積在內存裏，致使 Redis 的內存被耗盡。

咋整？答案是走內存淘汰機制。

內存淘汰機制都有哪些？

Redis 內存淘汰機制有如下幾個：

• noeviction: 當內存不足以容納新寫入數據時，新寫入操做會報錯。這個通常沒啥人用吧，太傻了。
• allkeys-lru：當內存不足以容納新寫入數據時，在鍵空間中，移除最近最少使用的 key（這個是最經常使用的）。
• allkeys-random：當內存不足以容納新寫入數據時，在鍵空間中，隨機移除某個 key。這個通常沒人用吧，爲啥要隨機，確定是把最近最少使用的 key 給幹掉啊。
• volatile-lru：當內存不足以容納新寫入數據時，在設置了過時時間的鍵空間中，移除最近最少使用的 key（這個通常不太合適）。
• volatile-random：當內存不足以容納新寫入數據時，在設置了過時時間的鍵空間中，隨機移除某個 key。這個通常也沒人用吧。
• volatile-ttl：當內存不足以容納新寫入數據時，在設置了過時時間的鍵空間中，有更早過時時間的 key 優先移除。

接下來，面試官就有可能要求手寫一個 LRU 算法了，從頭開始寫確實有點困難，那代碼量太大了，現場寫也不大現實，可是藉助 JDK 的現有的數據結構，寫一個 LRU ，仍是應該掌握下的，篇幅緣由，我就不貼代碼了，這一段代碼一搜一大把，你們本身百度吧。

緩存雪崩、擊穿、穿透

這幾個問題也是在面試中常常會問到的，由於在實際的使用過程當中，這一部份內容每每牽動了整個系統的安全性以及穩定性。

緩存雪崩

先了解下什麼是緩存雪崩？

我先描述兩個使用場景：

場景一：

線上正在運行的系統，突發情況， Redis 掛掉了，致使大量的數據訪問不走 Redis ，直接落在了 DB 上，DB 扛不住這麼大量的訪問，直接崩掉了，這時若是 BD 是獨立使用還好，若是不是獨立的， DB 還和其餘業務功能共享，那麼勢必會致使其餘使用同一 DB 的業務功能一塊兒崩掉，又會致使依賴於這些業務功能的其餘系統接着完蛋，結果就是全部的系統和功能一塊兒上天，這時，可能祭天一個程序員就不夠了，整個 IT 部都要一塊兒上天了。

場景二：

好比說電商平臺，首頁的熱點數據都是放在緩存中的，早晨 8 點刷新了一批熱點數據，設置有效期是 4 個小時，而在這 4 個小時中，並無刷新新的熱點數據，恰巧在中午 12 點的時候有一個秒殺活動。

悲慘的結果已經能夠預見了，當時間走到 12 點，熱點數據集體失效，而秒殺活動致使大量的用戶瘋狂的涌入，熱點數據不存在，請求的數據直接落到了 DB 上，致使 DB 崩掉，重複一遍和場景一同樣的慘況，整個 IT 部被拿來送上太陽，和咱們的特朗普老師肩並肩。

上面兩個場景的結果都是同樣的，由於 Redis 的功能不可用，致使 BD 上天，從而致使 IT 部集體飛昇。最坑的是這種事情發生後，尚未一個簡單易行的處理方案，由於單純的重啓恢復服務這個套路已經不適用了，流量大的狀況下，服務是起不來的好哇，服務剛起來就被流量幹爬下，這種事情在國內某知名互聯網公司發生過。只能是先在網關把全部流量攔截掉，而後恢復後端服務，並同步補充 Redis 的熱 key ，等這些事情都 ok 之後，才能將流量放進來從新恢復服務，這麼一套搞下來，幾個小時沒有了吧，固然，這個耗時視公司的不一樣而不一樣。

那麼這種狀況應該如何處理，先說說場景二，首先是不能使得全部的熱點 key 同時失效，這裏簡單加一個隨機數就行了，尤爲是電商首頁這種場景，直接設置熱 key 永不失效都是能夠的，要更新數據就直接更新，惟一的好處就是保險。

那麼場景一這種狀況咱們還有什麼解決方案呢？

首先，第一步要作到的就是 Redis 的高可用，隨便什麼方案，但絕對不能是單機，集羣怎麼也比單機掛掉的機率要小得多。

接下來，就是程序要啓用本地 ehcache 緩存，還要加上服務限流與降級，服務限流降級前 Netflix 提供的 hystrix 後有 Alibaba 提供的 Sentinel ，選用什麼看本身的使用場景，有了這個，至少保證了 BD 不會被一下打死，至少保證了服務的部分可用，哪怕只能保證 20% 的可用，對於用戶來說，就是多刷新幾回頁面的事情。

最後就是必定要開啓 Redis 的持久化， Redis 一旦重啓，自動從磁盤上加載數據，快速恢復緩存數據。

緩存穿透

什麼是緩存穿透？

仍是講一個場景，好比個人數據 id 是從 0 開始的自增序列，普通人請求沒啥問題，每次都是用一個正常的 id 來進行訪問，可是總有刁民搞事情，每次訪問都使用 id 爲 -1 來進行訪問，由於 -1 並不存在，全部在 Redis 中也不會進行緩存，每次查詢 DB 也查不到結果，這種請求直接無視了緩存的存在，直接做用於 DB ，只要訪問量超過必定的數量，就會直接把數據庫打死。

這種場景的解決方案其實很簡單，好比咱們能夠在程序中對數據的合法性進行校驗，若是數據不合法直接返回，好比上面的例子，若是 id 小於 0 ，直接返回失敗。

可是單純的這麼操做並不能解決全部的問題，有時候咱們並很差判斷數據的合法性，就好比上面那個場景，好比數據中 id 最大隻有 500 ，可是某些刁民老用一些大值進行請求，好比說 1000 ，這時雖然數據合法，但仍是會落在 DB 上，這裏我再提供一個簡單粗暴的方式，當發現數據沒查到數據的時候，在緩存中對這個 key 設置空的 value ，下次再進來就會去走緩存而不會落到 BD 上，這樣也能有效防止緩存穿透。

緩存擊穿

緩存擊穿和雪崩是有點像的，雪崩是大批量的熱 key 集體失效或者是不可用，致使請求直接落在 DB 上而打崩 DB ，最終致使整個系統的癱瘓。

而緩存擊穿是指在某些狀況下，會有一個極熱極熱的 key ，在扛着很是很是大的併發，忽然過時失效，致使全部的請求在一瞬間落在了 DB 上，瞬間擊垮 DB 致使全局崩盤。

看到這不知道你們想到了誰，反正我想到的是那個號稱七星軌的軟件，固然哈，人家的問題並非緩存擊穿，是真的扛不住，緩存直接被打崩了，畢竟我國的全民吃瓜，這個流量仍是至關猛的。

都說到這了順便聊聊它們的狀況，第一次是否是緩存擊穿如今已經無從考證了，基於這麼屢次的崩潰看下來，它們家的問題並非軟件層面的問題了，是硬件直接就不夠，貌似每次解決問題都是直接聯繫阿里雲擴容，阿里雲容量一擴上去問題立馬就沒了。

你若是非要問硬件爲何不夠，很簡單麼，那麼多硬件不要錢啊，帶寬不要錢的啊，你給啊，如今硬件帶寬開那麼高，又不是每天都有明星出軌咱們都有瓜吃，空出來的浪費啊。

如今這種操做就挺好，平時硬件夠用就行，明星出軌臨時擴容，事件熱點下降後再縮容回去，最近幾回我看到擴容的速度明顯快不少了，好幾回從我知道崩了不能用到服務恢復只有不到半小時（也有多是我消息閉塞），感受阿里雲的團隊和某博的團隊在經歷了這麼多大瓜之後已經能配合的很是默契了。

扯回來，咱們接着說緩存擊穿怎麼處理。

不一樣場景下的解決方式以下：

• 若緩存的數據是基本不會發生更新的，則可嘗試將該熱點數據設置爲永不過時。
• 若緩存的數據更新不頻繁，且緩存刷新的整個流程耗時較少的狀況下，則能夠採用基於 Redis、zookeeper 等分佈式中間件的分佈式互斥鎖，或者本地互斥鎖以保證僅少許的請求能請求數據庫並從新構建緩存，其他線程則在鎖釋放後能訪問到新緩存。
• 若緩存的數據更新頻繁或者在緩存刷新的流程耗時較長的狀況下，能夠利用定時線程在緩存過時前主動地從新構建緩存或者延後緩存的過時時間，以保證全部的請求能一直訪問到對應的緩存。

您的掃碼關注，是對小編堅持原創的最大鼓勵：）