之前常聽人說，但是沒有仔細想過這些問題。最近看《可伸縮服務架構-架構與中介軟體》中這些問題解釋的很好，也給出了一般解決方案，記錄一下。
快取穿透、快取併發、快取雪崩常見的由於併發量大而導致。
說明：
快取穿透指的是使用不存在的key進行大量的高併發查詢，這導致快取無法命中，每次請求都要穿透到後端資料庫系統進行查詢，使資料庫壓力過大，甚至使資料庫服務被壓死。
解決：
我們通常將空值快取起來，再次接收到同樣的查詢請求時，若命中快取並且值為空，就會直接返回，不會透傳到資料庫，避免快取穿透。當然，有時惡意襲擊者可以猜到我們使用了這種方案，每次都會使用不同的引數來查詢，這就需要我們對輸入的引數進行過濾，例如，如果我們使用id進行查詢，則可以對id的格式進行分析，如果不符合產生id的規則，就直接拒絕，或者在id上放入時間資訊，根據時間資訊判斷id是否合法，或者是否是我們曾經生成的id，這樣可以攔截一定的無效請求。
當然，每個設計人員都應該對服務的可用性和健壯性負責，應該建設健壯的服務，讓我們的服務像不倒翁一樣，因此，我們需要對服務設計限流和熔斷等功能。
說明：
快取併發的問題通常發生在搞併發的場景下，當乙個快取key過期時，因為訪問這個快取key的請求量較大，多個請求同時發現快取過期，因此多個請求會同時訪問資料庫來查詢最新資料，並且回寫快取，這樣會造成應用和資料庫的負載增加，效能降低，由於併發較高，甚至會導致資料庫被壓死。
解決：
我們通常有3種方式來解決這個問題。
分布式鎖
使用分布式鎖，保證對於每個key同時只有乙個執行緒去查詢後端服務，其他執行緒沒有獲得分布式鎖的許可權，因此只需要等待即可。這種方式將高併發的壓力轉移到了分布式鎖，因此對分布式鎖的考驗很大。
本地鎖
與分布式鎖類似，我們通過本地鎖的方式來限制只有乙個執行緒去資料庫中查詢資料，而其他執行緒只需要等待，等前面的執行緒查詢到資料後再訪問快取。但是，這種方法只能限制乙個服務節點只有乙個執行緒去資料庫中查詢，如果乙個服務有多個節點，則還會有多個資料庫查詢操作，也就是說在節點數量較多的情況下並沒有完全解決快取併發的問題。
軟過期
軟過期指對快取中的資料設定失效時間，就是不使用快取服務提供的過期時間，而是業務層在資料中儲存時間資訊，由業務程式判斷是否過期並更新，在發現了資料即將過期時，將快取的時效延長，程式可以派遣乙個執行緒去資料庫中獲取最新的資料，其他執行緒這時看到延長了的過期時間，就會繼續使用舊資料，等派遣的執行緒獲取最新資料後再更新快取。
也可以通過非同步更新設定軟過期的快取，這樣應用層就不用關心快取併發的問題了。
說明：
快取雪崩指快取伺服器重啟或者大量快取集中在某個時間段內失效，給後端資料庫造成瞬間的負載公升高壓力，甚至壓垮資料庫的情況。
解決：
通常的解決方法是對不同的資料使用不同的失效時間，甚至對相同的資料、不同的請求使用不同的失效時間，例如，我們要快取user資料，會對每個使用者的資料設定不同的快取過期時間，可以定義乙個基礎時間，假設10秒，然後加上乙個兩秒以內的隨機數，過期時間為10～12秒，就會避免快取雪崩。
引用《可伸縮服務架構-架構與中介軟體》
快取三大問題再總結
快取三大問題再總結 1 快取穿透 定義 快取穿透是指查詢乙個一定不存在的資料，由於快取是不命中時需要從資料庫查詢，查不到資料則不寫入快取，這將導致這個不存在的資料每次請求都要到資料庫去查詢，進而給db帶來壓力。解決 方案一 快取空資料 優點 簡單 缺點 效果不好 1 第一次查詢需要查庫 2 如果換另...
如何應對快取三大問題
快取擊穿 首先我們來看下請求是如何取到資料的 當接收到使用者請求，首先先嘗試從redis快取中獲取到資料，如果快取中能取到資料則直接返回結果，當快取中不存在資料時從db獲取資料，如果資料庫成功取到資料，則更新redis，然後返回資料 定義 高併發的情況下，某個熱門key突然過期，導致大量請求在red...
Redis快取三大問題解析
通俗來講，快取粒度問題就是我們在使用快取時，是將所有資料快取還是快取部分資料？快取粒度問題是乙個容易被忽視的問題，如果使用不當，可能會造成很多無用空間的浪費，可能會造成網路頻寬的浪費，可能會造成 通用性較差等情況，必須學會綜合資料通用性 空間占用比 維護性 三點評估取捨因素權衡使用。快取穿透是指查詢...