緩存是我們項目應用肯定會使用，是我們數據庫的守護神，能夠保證數據庫的穩定，能夠提高整個系統的性能。一般我們采用市面上的redis、memcahce方案；redis已經非常強大了，每秒支持幾萬的連接時不成問題。

上圖商品服務要獲取商品信息時，先從redis緩存中獲取，緩存中不存在再到數據庫中取；數據庫的資源時比較寶貴的，這樣的設計就能把一些請求轉移到redis上面去。這是我們小伙伴常用的緩存設計，絕大部分的緩存也就設計到此了。但只有這樣的設計，真的我們就可以安枕無憂了嗎？老顧帶著大家了解一下雪崩，穿透，擊穿的含義。

緩存雪崩

雪崩是指我們一般在設置緩存的時候都會設置一個緩存過期時間，如果一些緩存過期時間在同一刻，也就是緩存同時過期了。這個時候有大量請求過來，發現緩存中不存在，就直接到數據庫中獲取，就像雪崩一樣同時打到數據庫上面，這樣就會導致數據庫負載高，很有可能就會崩潰。

解決方案一：

發現緩存不存在，在讀取數據庫時，再保存到redis緩存中，采用隊列的方式或加鎖的方式，進行排隊訪問數據庫，這樣就能夠避免同時打到數據庫上。

解決方案二：

這個方案就比較簡單，雪崩是因為過期時間在同一刻導致的，那我們就可以在設置過期時間分散開。如在原有的過期時間的基礎上加上一個 隨機數，比如：1～10分鐘，這樣就不會放生在同一刻緩存失效了。

解決方案三：

設置二級緩存機制，這樣就能夠保證即時第一層緩存失效了，還有第二級緩存的保障；不過就增加了系統復雜性。

緩存穿透

穿透是指在查詢一個不存在的數據，如商品id=10000，系統就不存在id為10000的數據。按照緩存設計的原理，緩存中找不到此商品，就會到數據庫中查詢，也沒有找到。這樣的請求都會打到數據庫中，緩存在這個場景中就相當于沒有。惡意的人利用這個漏洞發起攻擊，直接把數據庫搞崩潰。

解決方案一：

最常見的方法就是采用布隆過濾器，將所有可能存在的數據哈希到一個足夠大的map中，一定不存在的數據會被這個map過濾掉，這樣就避免了訪問到數據庫。

解決方案二：

就是把空值也緩存起來，如商品id=10000，數據庫查詢雖然沒有找到，但會在redis中保存一個空值。這種方案就會碰到2個問題。

問題一：

空值做了緩存，這樣就無形了增加了很多沒有意義的緩存，內存吃緊。比較有效的方式就是在這些值上面設置一個過期時間，讓起自動刪除

問題二：

有可能與業務存在不一致的窗口時間，如：雖然商品ID=10000現在不存在，我們現在在redis中保存了一個空值，但業務后來就真的有了商品id為10000的數據，這樣數據庫和緩存的信息就不一致，導致業務出現問題。此時就可以利用消息中間件等方式系統剔除掉此緩存數據

緩存擊穿

擊穿是指某些數據被大量請求，也就是“熱點”數據，一旦出現緩存過期時，就會有大量的請求打到后端的數據庫，這樣就會導致數據庫崩潰

解決方案一：檢測更新

最容易想到的是這些熱點數據設置永不過期，就不存在此問題。這樣就會出現一個問題，那緩存怎么去更新呢？

方法一：

可以做一個后臺服務，專門用來做數據緩存的更新。每隔30分鐘更新一下這些熱點緩存數據。不過這樣就增加了系統復雜度。

方法二：

方法一過于復雜，我們可以改造一下redis的緩存結構，在緩存業務數據的時候，再保存跟業務數據關聯的過期時間key。每次請求過來時，判斷一下此業務數據的是否要到過期時間了，如：此值還有1分鐘就過期了，這樣就服務本身主動去數據庫查詢一次，做一個緩存的更新。

解決方案二：分級緩存

分級緩存，可采用二級緩存的方式緩存此熱點數據。

采用 L1 （一級緩存）和 L2（二級緩存） 緩存方式，L1 緩存失效時間短，L2 緩存失效時間長。 請求優先從 L1 緩存獲取數據，如果 L1緩存未命中則加鎖，只有 1 個線程獲取到鎖，這個線程再從數據庫中讀取數據并將數據再更新到到 L1 緩存和 L2 緩存中，而其他線程依舊從 L2 緩存獲取數據并返回。

這種方式，主要是通過避免緩存同時失效并結合鎖機制實現。所以，當數據更新時，只能淘汰 L1 緩存，不能同時將 L1 和 L2 中的緩存同時淘汰。L2 緩存中可能會存在臟數據，需要業務能夠容忍這種短時間的不一致。而且，這種方案可能會造成額外的緩存空間浪費。

解決方案三：加鎖

也就是在獲取數據時，redis緩存不存在，在訪問數據庫時，通過加鎖的方式獲取數據庫的值，這樣就保證了訪問數據庫只有一個請求過來，從而保證數據庫的負載。
責任編輯人：CC