redis快取的使用，極大的提公升了應用程式的效能和效率，特別是資料查詢方面。但同時，它也帶來了一些問題。其中，最要害的問題，就是資料的一致性問題(事務在執行時不能保證原子性)，從嚴格意義上講，這個問題無解。如果對資料的一致性要求很高，那麼就不能使用快取。
另外的一些典型問題就是，快取穿透、快取雪崩和快取擊穿。目前，業界也都有比較流行的解決方案。
概念快取穿透的概念很簡單，使用者想要查詢乙個資料，發現redis記憶體資料庫沒有，也就是快取沒有命中，於是向持久層資料庫查詢。發現也沒有，於是本次查詢失敗。當使用者很多的時候，快取都沒有命中（秒殺！），於是都去請求了持久層資料庫。這會給持久層資料庫造成很大的壓力，這時候就相當於出現了快取穿透。洪水攻擊。資料庫也查不到就沒有快取，就會一直與資料庫訪問。
解決方案1.布隆過濾器對所有可能查詢的引數以hash的形式儲存，以便快速確定是否存在這個值，在控制層先進行攔截校驗，校驗不通過直接打回，減輕了儲存系統的壓力。
2.快取空物件
一次請求若在快取和資料庫中都沒找到，就在快取中放乙個空物件用於處理後續這個請求。
1、如果空值能夠被快取起來，這就意味著快取需要更多的空間儲存更多的鍵，因為這當中可能會有很多的空值的鍵；
2、即使對空值設定了過期時間，還是會存在快取層和儲存層的資料會有一段時間視窗的不一致，這對於需要保持一致性的業務會有影響
（量太大 快取過期）
概述相較於快取穿透，快取擊穿的目的性更強，乙個存在的key，在快取過期的一刻，同時有大量的請求，這些請求都會擊穿到db，造成瞬時db請求量大、壓力驟增。這就是快取被擊穿，只是針對其中某個key的快取不可用而導致擊穿，但是其他的key依然可以使用快取響應。
比如熱搜排行上，乙個熱點新聞被同時大量訪問就可能導致快取擊穿。
解決方案1.設定熱點資料永不過期這樣就不會出現熱點資料過期的情況，但是當redis記憶體空間滿的時候也會清理部分資料，而且此種方案會占用空間，一旦熱點資料多了起來，就會占用部分空間。
2.加互斥鎖(分布式鎖)
在訪問key之前，採用setnx（set if not exists）來設定另乙個短期key來鎖住當前key的訪問，訪問結束再刪除該短期key。保證同時刻只有乙個執行緒訪問。這樣對鎖的要求就十分高。
快取雪崩
快取概念大量的key設定了相同的過期時間，導致在快取在同一時刻全部失效，造成瞬時db請求量大、壓力驟增，引起雪崩。
解決方案
redis高可用
這個思想的含義是，既然redis有可能掛掉，那我多增設幾台redis，這樣一台掛掉之後其他的還可以繼續工作，其實就是搭建的集群
限流降級
這個解決方案的思想是，在快取失效後，通過加鎖或者佇列來控制讀資料庫寫快取的執行緒數量。比如對某個key只允許乙個執行緒查詢資料和寫快取，其他執行緒等待。
資料預熱
資料加熱的含義就是在正式部署之前，我先把可能的資料先預先訪問一遍，這樣部分可能大量訪問的資料就會載入到快取中。在即將發生大併發訪問前手動觸發載入快取不同的key，設定不同的過期時間，讓快取失效的時間點盡量均勻。
redis 快取穿透與快取雪崩
快取穿透 快取系統，按照 key去查詢 value,當key 對應的value 一定不存在的時候並對 key併發請求量很大的時候，就會對後端造成很大的壓力。如何避免 1.對查詢機構為空的情況也進行快取，快取的時間設定端一點，或者對該 key對應的資料 insert 之後清理快取。2.對一定不存在的 ...
Redis快取穿透 快取雪崩
把redis作為快取使用已經是司空見慣，但是使用redis後也可能會碰到一系列的問題，尤其是資料量很大的時候，經典的幾個問題如下 一 快取和資料庫間資料一致性問題 分布式環境下 單機就不用說了 非常容易出現快取和資料庫間的資料一致性問題，針對這一點的話，只能說，如果你的專案對快取的要求是強一致性的，...
Redis 快取穿透 快取雪崩
目錄 1.快取穿透 如何避免？如何選擇？2 快取擊穿 如何解決 3.快取雪崩 如何解決？快取穿透 一般的快取系統，都是按照key去快取查詢，如果不存在對應的value，就應該去後端系統查詢 比如db 一些惡意的請求會故意查詢不存在的key，請求量很大，就會對後端系統造成很大的壓力，或導致資料庫異常。...