Redis 快取穿透和雪崩

快取擊穿（量太大，快取過期）

快取雪崩

解決方案

redis 快取的使用，極大地提公升了應用程式的效能和效率，特別是資料查詢方面。但同時，它也帶來了一些問題，最要害的問題就是資料的一致性問題，從嚴格意義上來講，這個問題無解。如果對資料的一致性要求很高，那麼就不能使用快取

另外的一些經典問題就是，快取穿透、快取雪崩和快取擊穿。目前，業界也都有比較流行的解決方案

快取穿透的概念很簡單，使用者想要查詢乙個資料，發現 redis 記憶體資料庫沒有，也就是快取沒有命中，於是向持久層資料庫查詢，發現也沒有，於是本次查詢失敗。當使用者很多的時候，快取都沒有命中（秒殺），於是都去請求了持久層資料庫。這會給持久層資料庫造成很大的壓力，這時候就相當於出現了快取穿透

布隆過濾器

布隆過濾器是一種資料結構，對所有可能查詢的引數以 hash 形式儲存，在控制層先進行校驗，不符合則丟棄，從而避免了對底層儲存系統的查詢壓力

快取空物件

當儲存層不命中後，即使返回的空物件也將其快取起來，同時會設定乙個過期時間，之後再訪問這個資料庫將會從快取中獲取，保護了後端資料來源

但是這種方法會存在兩個問題：

這裡需要注意和快取穿透的區別，快取擊穿是指乙個 key 非常熱點，在不停地扛著大併發，大併發集中對這乙個點進行訪問，當這個 key 在失效的瞬間，持續的大併發就穿破快取，直接請求資料庫，就像在乙個屏障上鑿開了乙個洞

當某個 key 在過期的瞬間，有大量的請求併發訪問，這類資料一般是熱點資料，由於快取過期，會同時訪問資料庫來查詢最新資料，並且回寫快取，會導致資料庫瞬間壓力過大

設定熱點資料永不過期

從快取層面來看，沒有設定過期時間，所以不會出現熱點 key 過期後產生的問題

加互斥鎖

分布式鎖：使用分布式鎖，保證對於每個 key 同時只有乙個執行緒去查詢後端服務，其它執行緒沒有獲得分布式鎖的許可權，因此只需要等待即可。這種方式將高併發的壓力轉移到了分布式鎖，因此對分布式鎖的考驗很大

快取雪崩，是指在某乙個時間段，快取集中過期失效，redis 宕機

產生雪崩的原因之一，比如在寫本文的時候，馬上就要 12 點了，很快就會迎來一波搶購，這波商品時間比較集中的放入了快取，假設快取乙個小時。那麼到了凌晨一點中的時候，這批商品的快取就都過期了。而對這批商品的訪問查詢，都落到了資料庫上，對於資料庫而言，就會產生週期性的壓力波峰。於是所有的請求都會達到儲存層，儲存層的呼叫會暴增，造成了儲存層也會掛掉的情況

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

1、redis 高可用

這個思想的含義是，既然 redis 有可能掛掉，那我多增幾台 redis，這樣一台掛掉之後其它的還可以繼續工作，其實就是搭建的集群（異地多活）

2、限流降級

這個解決方案的思想是，在快取失效後，通過加鎖或者佇列來控制讀資料庫寫快取的執行緒數量。比如對某個 key 只允許乙個執行緒查詢資料和寫快取，其它執行緒等待

3、資料加熱

資料加熱的含義就是在正式部署之前，先把可能的資料先預先訪問一遍，這樣部分可能大量訪問的資料就會載入到快取中。在即將發生大併發訪問前手動觸發載入快取不同的 key，設定不同的過期時間，讓快取失效的時間點盡量均勻

Redis快取穿透和雪崩

快取的目的是什麼？提高效能，快取查詢的速度比去資料庫查詢要快。快取會分擔部分請求，減少併發壓力。那麼快取穿透是什麼？怎麼解決快取穿透呢？一般快取系統，按key去查詢value,如果不存在相應的key，那麼就會去資料庫查詢，如果key對應的value是一定不存在的，並且對key的併發查詢很高，那麼每次...

Redis 快取穿透和雪崩

快取穿透是指快取和資料庫中都沒有的資料，而使用者不斷發起請求，如發起為id為 1 的資料或id為特別大不存在的資料。這時候就會繞過快取，每次都請求資料庫，這樣的話，大量的請求都直接到達資料庫，這種現象就叫快取穿透。list list demoservice.getdemodata demoid 防止...

Redis快取穿透和雪崩

服務的高可用問題 redis快取的使用，極大的提公升了應用程式的效能和效率，特別是資料查詢方面。但同時，它也帶來了一 些問題。其中，要害的問題，就是資料的一致性問題，從嚴格意義上講，這個問題無解。如果對資料 的一致性要求很高，那麼就不能使用快取。另外的一些典型問題就是，快取穿透 快取雪崩和快取擊穿。...