由於 CSDN 改版之後導致頁面丟失了太多的東西，現已將博客遷移到自己的小站去了：
地址：http://www.wangchunlong.cn/article/8
使用緩存通常的操作時先訪問緩存數據，如果緩存中不存在的話，就會回源到數據庫中然後將數據寫入到緩存中。如果存在就直接返回數據，從整個過程來看，緩存層就處於數據庫的前置環節，分擔了數據庫在高併發容易出現故障的風險，所以在使用過程中需要對緩存層很謹慎的進行分析。在訪問緩存數據時，有常見的三大場景：緩存穿透、緩存擊穿以及緩存雪崩
1.1、緩存穿透
現象：每次請求直接穿過緩存層，直接會員到數據庫中，給數據庫帶來了巨大的壓力，嚴重甚至會導致宕機，出現嚴重的生產事故
原因：訪問數據會先訪問緩存，如果數據不存在緩存中才會查詢數據庫，但是如果查詢數據也查詢不出來數據，也就是說當前訪問數據永遠不會寫入緩存中，這樣就導致了訪問一定不存在的數據，就相當於緩存層形同虛設，每次請求都會到DB，造成數據庫壓力過大
解決方案：
- 1、如果DB 查詢不到數據，保存空對象到緩存層，設置較短的失效時間
- 2、針對業務場景對參數進行有效性效驗，防止非法請求擊垮DB
- 3、採用布隆過濾器，這種過濾器可以過濾掉大部分不存在的數據，防止這些數據請求到DB。（這種方法我也不太瞭解，只知道概念，沒用過）
1.2、 緩存擊穿
現象：當某一 key 失效時，造成大量請求到 DB 層，擊垮存儲層
原因：爲了保證緩存數據的有效性，通常會設置一個失效時間，如果是熱點 key ，高併發時會有海量請求直接越過緩存層到數據庫，這樣就會給數據庫趙成很大的負擔，嚴重可能會導致宕機
解決方案：
- 1、使用互斥鎖，當緩存數據失效時，保證一個請求能夠訪問導數據，並更新緩存，其他線程等待並重試。
- 2、緩存數據“永不過期”，如果緩存數據不設置失效時間的話，就不會存在熱點 key 過期造成的大量請求到數據庫。但是，緩存數據舊變成“靜態數據”，因此當緩存數據快要過期時採用異步線程的方式提前進行更新緩存數據
1.3、緩存雪崩
現象：多個key失效，造成大量請求到 DB層，導致 DB 層負擔過重甚至宕機
原因：緩存雪崩是指在設置緩存的時候設置了同樣的過期時間，導致緩存統一時間失效，失效後全部請求就轉發到了數據庫，造成數據庫一瞬間壓力過大而導致數據庫崩潰。
解決方案：
- 多每個 key 的失效時間的基礎上設置一個隨機時間，把失效時間給分佈在多個時間節點上，這樣就減少了key 在大規模集體失效的可能性。
- 使用互斥鎖，保證每一相同的請求只允許單個線程進行 DB 查詢
總結：
一般出現這幾種問題都是系統設計的問題，如果設計得合理的話幾乎不會出現這些問題。
緩存穿透強調是獲取本不存在的緩存數據，請求必然會越過緩存層直接到達緩存層，很明顯這是利用業務規則的漏洞會系統發起攻擊，解決方案的核心原則是過濾這些非法業務請求，與是否是熱點數據、緩存失效時間等因素沒有關係。
緩存擊穿強調的是熱點 key 的失效，導致某一時刻大量請求會直接到 DB 層，解決方案的核心原則是規避數據庫的併發操作。
緩存雪崩強調的多個 key 的解決失效，與 key 是否是熱點數據並不是必然的因素，解決方案的核心原則則是讓 key 之間的失效時間分佈更加均勻，避免集體失效的情況