本篇文章主要談談Redis中很容易出現的三大問題現象：緩存擊穿、緩存穿透以及緩存雪崩。不過在介紹這三個問題現象之前，我們首先需要先來了解下Redis中key的過期淘汰機制。眾所周知，Redis可以對存儲在Redis中的緩存數據設置過期時間，比如我們獲取的短信驗證碼一般十分鐘過期，我們這時候就需要在驗證碼存進Redis時添加一個key的過期時間，但是這里有一個需要格外注意的問題就是：并非key過期時間到了就一定會被Redis給刪除。那么Redis是如何做到對過期key進行刪除呢？Redis中對于過期key的刪除分為兩種策略：定期刪除和惰性刪除。

• 定期刪除：Redis 默認是每隔 100ms 就隨機抽取一些設置了過期時間的 Key，檢查其是否過期，如果過期就刪除。為什么是隨機抽取而不是檢查所有key？因為你如果設置的key成千上萬，每100毫秒都將所有存在的key檢查一遍，會給CPU帶來比較大的壓力。
• 惰性刪除 ：定期刪除由于是隨機抽取可能會導致很多過期 Key 到了過期時間并沒有被刪除。所以用戶在從緩存獲取數據的時候，redis會檢查這個key是否過期了，如果過期就刪除這個key。這時候就會在查詢的時候將過期key從緩存中清除。

但是如果僅僅使用定期刪除 + 惰性刪除機制還是會留下一個嚴重的隱患：如果定期刪除留下了很多已經過期的key，而且用戶長時間都沒有使用過這些過期key，導致過期key無法被惰性刪除，從而導致過期key一直堆積在內存里，最終造成Redis內存塊被消耗殆盡。那這個問題如何解決呢？這個時候Redis內存淘汰機制應運而生了。Redis內存淘汰機制提供了6種數據淘汰策略：

• volatile-lru：從已設置過期時間的數據集中挑選最近最少使用的數據淘汰。
• volatile-ttl：從已設置過期時間的數據集中挑選將要過期的數據淘汰。
• volatile-random：從已設置過期時間的數據集中任意選擇數據淘汰。
• allkeys-lru：當內存不足以容納新寫入數據時移除最近最少使用的key。
• allkeys-random：從數據集中任意選擇數據淘汰。
• no-enviction：當內存不足以容納新寫入數據時，新寫入操作會報錯。

一般情況下，推薦使用volatile-lru策略，對于配置信息等重要數據，不應該設置過期時間，這樣Redis就永遠不會淘汰這些重要數據。對于一般數據可以添加一個緩存時間，當數據失效則請求會從DB中獲取并重新存入Redis中。

緩存擊穿

講完了Redis的key的過期淘汰機制，接下我們可以進入正題：為什么會出現緩存擊穿、緩存穿透和緩存雪崩現象呢？首先我們來看下請求是如何取到數據的：當接收到用戶請求，首先先嘗試從Redis緩存中獲取到數據，如果緩存中能取到數據則直接返回結果，當緩存中不存在數據時從DB獲取數據，如果數據庫成功取到數據，則更新Redis，然后返回數據，如果DB無數據，則返回空結果。那什么情況下會出現三大問題現象呢？我們先來看下緩存擊穿的情況：

定義：高并發的情況下，某個熱門key突然過期，導致大量請求在Redis未找到緩存數據，進而全部去訪問DB請求數據，引起DB壓力瞬間增大。

解決方案：緩存擊穿的情況下一般不容易造成DB的宕機，只是會造成對DB的周期性壓力。對緩存擊穿的解決方案一般可以這樣：Redis中的數據不設置過期時間，然后在緩存的對象上添加一個屬性標識過期時間，每次獲取到數據時，校驗對象中的過期時間屬性，如果數據即將過期，則異步發起一個線程主動更新緩存中的數據。但是這種方案可能會導致有些請求會拿到過期的值，就得看業務能否可以接受，如果要求數據必須是新數據，則最好的方案則為熱點數據設置為永不過期，然后加一個互斥鎖保證緩存的單線程寫。

緩存穿透

定義：緩存穿透是指查詢緩存和DB中都不存在的數據。比如通過id查詢商品信息，id一般大于0，攻擊者會故意傳id為-1去查詢，由于緩存是不命中則從DB中獲取數據，這將會導致每次緩存都不命中數據導致每個請求都訪問DB，造成緩存穿透。

解決方案：緩存穿透的解決方案可以分成兩個部分：首先在API層增加基本校驗：用戶鑒權校驗，id校驗。比如用戶鑒權失敗或者id < 0的請求直接進行攔截。其次在緩存和DB都取不到數據的時候將將key-value存儲成key-null存儲到Redis， 過期時間可以存儲的短點比如60S，防止短時間內攻擊者不斷發起請求導致數據庫壓力過大出現宕機。

緩存雪崩

定義：緩存中如果大量緩存在一段時間內集中過期了，這時候會發生大量的緩存擊穿現象，所有的請求都落在了DB上，由于查詢數據量巨大，引起DB壓力過大甚至導致DB宕機。

解決方案：緩存雪崩一般沒有完美解決的方法，但是我們可以盡量分析用戶行為，盡量保證key的失效時間比較平均，防止同一時間出現大量緩存數據同時過期的現象，并且設置熱點數據永不過期。同時如果為分布式環境下，使用分布式鎖來保證緩存的單線程寫，這樣可以避免同一時間大量緩存失效導致請求全部落在DB上。而我覺得如果可以接受有些請求拿到過期值，最合理的方案實際上就是使用緩存擊穿的方案：Redis中的數據不設置過期時間，然后在緩存的對象上添加一個屬性標識過期時間，每次獲取到數據時，校驗對象中的過期時間屬性，如果數據即將過期，則異步發起一個線程主動更新緩存中的數據。