使用者想要查詢乙個資料，發現redis記憶體資料庫沒有，也就是快取沒有命中，於是向持久層資料庫查詢。發現也沒有，於是本次查詢失敗。當使用者很多的時候，快取都沒有命中，於是都去請求了持久層資料庫。這會給持久層資料庫造成很大的壓力，這時候就相當於出現了快取穿透。
比如，發起乙個id=-1的資料庫查詢請求。
布隆過濾器是一種資料結構，對所有可能查詢的引數以hash形式儲存，在控制層先進行校驗，不符合則丟棄，從而避免了對底層儲存系統的查詢壓力。
當儲存層不命中後，即使返回的空物件也將其快取起來，同時會設定乙個過期時間，之後再訪問這個資料將會從快取中獲取，保護了後端資料來源。
問題：如果空值能夠被快取起來，這就意味著快取需要更多的空間儲存更多的鍵，因為這當中可能會有很多的空值的鍵。
即使對空值設定了過期時間，還是會存在快取層和儲存層的資料會有一段時間視窗的不一致，這對於需要保持一致性的業務會有影響。
快取擊穿是指乙個key非常熱點，在不停的扛著大併發，大併發集中對這乙個點進行訪問，當這個key在失效的瞬間，持續的大併發就穿破快取，直接請求資料庫，就像在乙個屏障上鑿開了乙個洞。
當某個key在過期的瞬間，有大量的請求併發訪問，這類資料一般是熱點資料，由於快取過期，會同時訪問資料庫來查詢最新資料，並且回寫快取，會導使資料庫瞬間壓力過大。
比如，秒殺的過程中，某個key突然過期，導致大量請求打到了資料庫上。
從快取層面來看，沒有設定過期時間，所以不會出現熱點 key過期後產生的問題。
使用分布式鎖，保證對於每個key同時只有乙個執行緒去查詢後端服務，其他執行緒沒有獲得分布式鎖的許可權，因此只需要等待即可。這種方式將高併發的壓力轉移到了分布式鎖，因此對分布式鎖的考驗很大。
快取雪崩，是指在某乙個時間段，快取集中過期失效。
比如，redis宕機。
這個思想的含義是，既然redis有可能掛掉，那我多增設幾台redis，這樣一台掛掉之後其他的還可以繼續工作，其實就是搭建的集群，保證異地多活。
這個解決方案的思想是，在快取失效後，通過加鎖或者佇列來控制讀資料庫寫快取的執行緒數量。比如對某個key只允許乙個執行緒查詢資料和寫快取，其他執行緒等待。
資料預熱的含義就是在正式部署之前，我先把可能的資料先預先訪問一遍，這樣部分可能大量訪問的資料就會載入到快取中。在即將發生大併發訪問前手動觸發載入快取不同的key，設定不同的過期時間，讓快取失效的時間點盡量均勻。
快取 redis 快取穿透
哪一些因素 考慮使用redis，畢竟 redis 也要增加成本 1 熱點資料 2 讀的成本非常大 3 讀多寫少 4 對資料一致性要求 沒有那麼嚴格 可以出現資料與資料庫不一致 1 秒殺場景 3 物流查詢軌跡 熱點資料 啟用的資料是被快取到redis 當中 快取key 乙個時間點過期的時候，如果快取資...
Redis快取穿透 快取雪崩
把redis作為快取使用已經是司空見慣，但是使用redis後也可能會碰到一系列的問題，尤其是資料量很大的時候，經典的幾個問題如下 一 快取和資料庫間資料一致性問題 分布式環境下 單機就不用說了 非常容易出現快取和資料庫間的資料一致性問題，針對這一點的話，只能說，如果你的專案對快取的要求是強一致性的，...
Redis 快取穿透 快取雪崩
目錄 1.快取穿透 如何避免？如何選擇？2 快取擊穿 如何解決 3.快取雪崩 如何解決？快取穿透 一般的快取系統，都是按照key去快取查詢，如果不存在對應的value，就應該去後端系統查詢 比如db 一些惡意的請求會故意查詢不存在的key，請求量很大，就會對後端系統造成很大的壓力，或導致資料庫異常。...