轉載：https://baijiahao.baidu.com/s?id=1619572269435584821&wfr=spider&for=pc

Redis緩存的使用，極大的提升了應用程序的性能和效率，特別是數據查詢方面。但同時，它也帶來了一些問題。其中，最要害的問題，就是數據的一致性問題，從嚴格意義上講，這個問題無解。如果對數據的一致性要求很高，那麽就不能使用緩存。

另外的一些典型問題就是，緩存穿透、緩存雪崩和緩存擊穿。目前，業界也都有比較流行的解決方案。本篇文章，並不是要更加完美的解決這三個問題，也不是要顛覆業界流行的解決方案。而是，從實際代碼操作，來演示這三個問題現象。之所以要這麽做，是因為，僅僅看這些問題的學術解釋，腦袋裏很難有一個很形象的概念，有了實際的代碼演示，可以加深對這些問題的理解和認識。

緩存穿透

緩存穿透，是指查詢一個數據庫一定不存在的數據。正常的使用緩存流程大致是，數據查詢先進行緩存查詢，如果key不存在或者key已經過期，再對數據庫進行查詢，並把查詢到的對象，放進緩存。如果數據庫查詢對象為空，則不放進緩存。

代碼流程

參數傳入對象主鍵ID根據key從緩存中獲取對象如果對象不為空，直接返回如果對象為空，進行數據庫查詢如果從數據庫查詢出的對象不為空，則放入緩存（設定過期時間）想象一下這個情況，如果傳入的參數為-1，會是怎麽樣？這個-1，就是一定不存在的對象。就會每次都去查詢數據庫，而每次查詢都是空，每次又都不會進行緩存。假如有惡意攻擊，就可以利用這個漏洞，對數據庫造成壓力，甚至壓垮數據庫。即便是采用UUID，也是很容易找到一個不存在的KEY，進行攻擊。

小編在工作中，會采用緩存空值的方式，也就是【代碼流程】中第5步，如果從數據庫查詢的對象為空，也放入緩存，只是設定的緩存過期時間較短，比如設置為60秒。

緩存雪崩

緩存雪崩，是指在某一個時間段，緩存集中過期失效。

產生雪崩的原因之一，比如在寫本文的時候，馬上就要到雙十二零點，很快就會迎來一波搶購，這波商品時間比較集中的放入了緩存，假設緩存一個小時。那麽到了淩晨一點鐘的時候，這批商品的緩存就都過期了。而對這批商品的訪問查詢，都落到了數據庫上，對於數據庫而言，就會產生周期性的壓力波峰。

小編在做電商項目的時候，一般是采取不同分類商品，緩存不同周期。在同一分類中的商品，加上一個隨機因子。這樣能盡可能分散緩存過期時間，而且，熱門類目的商品緩存時間長一些，冷門類目的商品緩存時間短一些，也能節省緩存服務的資源。

其實集中過期，倒不是非常致命，比較致命的緩存雪崩，是緩存服務器某個節點宕機或斷網。因為自然形成的緩存雪崩，一定是在某個時間段集中創建緩存，那麽那個時候數據庫能頂住壓力，這個時候，數據庫也是可以頂住壓力的。無非就是對數據庫產生周期性的壓力而已。而緩存服務節點的宕機，對數據庫服務器造成的壓力是不可預知的，很有可能瞬間就把數據庫壓垮。

緩存擊穿

緩存擊穿，是指一個key非常熱點，在不停的扛著大並發，大並發集中對這一個點進行訪問，當這個key在失效的瞬間，持續的大並發就穿破緩存，直接請求數據庫，就像在一個屏障上鑿開了一個洞。

小編在做電商項目的時候，把這貨就成為“爆款”。

其實，大多數情況下這種爆款很難對數據庫服務器造成壓垮性的壓力。達到這個級別的公司沒有幾家的。所以，務實主義的小編，對主打商品都是早早的做好了準備，讓緩存永不過期。即便某些商品自己發酵成了爆款，也是直接設為永不過期就好了。

大道至簡，mutex key互斥鎖真心用不上。

結束語

在流行的問題面前一定有流行的解決方案，但有時候，也要根據自己的實際情況酌情處理。大膽設計，說不定你的解決方案就會被流行呢？

實例解讀什麽是Redis緩存穿透、緩存雪崩和緩存擊穿