Redis緩存的使用，極大的提升了應用程序的性能和效率，特別是數據查詢方面。但同時，它也帶來了一些問題。其中，最要害的問題，就是數據的一致性問題，從嚴格意義上講，這個問題無解。如果對數據的一致性要求很高，那麼就不能使用緩存。
另外的一些典型問題就是，緩存穿透、緩存雪崩和緩存擊穿，其中緩存穿透和擊穿類似，都是不經過緩存直接到數據庫，不過前者主要強調緩存命中不了問題後者主要是強調緩存失效瞬間大量查詢攻擊請求問題
緩存穿透
緩存穿透，是指查詢一個數據庫一定不存在的數據。正常的使用緩存流程大致是，數據查詢先進行緩存查詢，如果
key不存在或者key已經過期，再對數據庫進行查詢，並把查詢到的對象，放進緩存。如果數據庫查詢對象爲空，
則不放進緩存。
參數傳入對象主鍵ID根據key從緩存中獲取對象如果對象不爲空，直接返回如果對象爲空，進行數據庫查詢如果從
數據庫查詢出的對象不爲空，則放入緩存（設定過期時間）想象一下這個情況，如果傳入的參數爲-1，會是怎麼
樣？這個-1，就是一定不存在的對象。就會每次都去查詢數據庫，而每次查詢都是空，每次又都不會進行緩存。假
如有惡意攻擊，就可以利用這個漏洞，對數據庫造成壓力，甚至壓垮數據庫。即便是採用UUID，也是很容易找到一
個不存在的KEY，進行攻擊。
可通過採用緩存空值的方式，如果從數據庫查詢的對象爲空，也放入緩存，只是設定的緩存過期時間較短，比如設
置爲60秒。
緩存空值
緩存雪崩
緩存雪崩，是指在某一個時間段，緩存集中過期失效。
產生雪崩的原因之一，比如在寫本文的時候，馬上就要到雙十二零點，很快就會迎來一波搶購，這波商品時間比較
集中的放入了緩存，假設緩存一個小時。那麼到了凌晨一點鐘的時候，這批商品的緩存就都過期了。而對這批商品
的訪問查詢，都落到了數據庫上，對於數據庫而言，就會產生週期性的壓力波峯。
尤其在做電商項目的時候，一般是採取不同分類商品，緩存不同週期。在同一分類中的商品，加上一個隨機因子。
這樣能儘可能分散緩存過期時間，而且，熱門類目的商品緩存時間長一些，冷門類目的商品緩存時間短一些，也能
節省緩存服務的資源。
緩存時間加入隨機因子
其實集中過期，倒不是非常致命，比較致命的緩存雪崩，是緩存服務器某個節點宕機或斷網。因爲自然形成的緩存
雪崩，一定是在某個時間段集中創建緩存，那麼那個時候數據庫能頂住壓力，這個時候，數據庫也是可以頂住壓力
的。無非就是對數據庫產生週期性的壓力而已。而緩存服務節點的宕機，對數據庫服務器造成的壓力是不可預知
的，很有可能瞬間就把數據庫壓垮。
緩存擊穿
緩存擊穿，是指一個key非常熱點，在不停的扛着大併發，大併發集中對這一個點進行訪問，當這個key在失效的
瞬間，持續的大併發就穿破緩存，直接請求數據庫，就像在一個屏障上鑿開了一個洞。
其實，大多數情況下這種爆款很難對數據庫服務器造成壓垮性的壓力。達到這個級別的公司沒有幾家的。所以，務
實主義的小編，對主打商品都是早早的做好了準備，讓緩存永不過期。即便某些商品自己發酵成了爆款，也是直接
設爲永不過期就好了。