編程界的小學生
一、緩存穿透
1、概念
比如電商網站，有以下商品在redis裏和mysql裏。且Redis裏只存放熱點商品， 而不是全部。
蘋果、香蕉、鴨梨等，但是用戶搜了個我這電商網站裏沒有賣的商品，這時候redis裏肯定沒有搜的數據，就去請求db了。db也不一定有（有可能有有可能沒有），如果沒有的話那白白浪費性能了。這就是緩存穿透。量少的話就別說了，量少都沒必要redis緩存。大量的話會很恐怖，比如淘寶，他無所不賣，萬一真找到一個不賣的東西去搜，然後redis沒有，結果都去請求mysql了。那不GG了嘛？
2、解決方案
二、緩存雪崩
1、概念
1.1、情況一
大批量熱點數據過期後，高併發請求，直接請求到db，引起db壓力造成查詢阻塞甚至宕機。
1.2、情況二
Redis掛了。導致請求都到db了。假設高併發5000個請求，本來緩存再高峯期可以抗住每秒4000個請求，但是Redis掛了，5000個請求直接幹到了數據庫層，這可能又把數據庫給打死了。
2、解決方案
2.1、情況一的解決方案
- 簡單粗暴，設置熱點數據永不過期（具體還看業務是否允許）
- 將緩存失效的時間分散開，比如每個熱點key的過期時間是隨機的，而不是每個key都一樣是固定的。這樣不會遇到同時大量熱點數據過期的情況，分批過期，將高併發大流量變成一部分一部分的小流量打給數據庫，這樣就沒問題了。
2.2、情況二的解決方案
- 加一層本地ehcache緩存。也就是請求進來先查ehcache緩存，ehcache沒有的話去查redis，redis也沒有再去db。這時候redis掛了，但是我們本地ehcache還有，所以不會打到db層。
- 限流組件，可以設置每秒最大請求數，超過最大請求數的那些請求怎麼辦？走降級！可以返回一些默認值，或者友情提示啥的。
限流的好處是數據庫絕對不會死，因爲限流組件保證了有多少請求能進來。只要數據庫不死，就能對外繼續提供請求。雖然有部分用戶請求走降級，但不是全部，會有大部分請求得到執行。
三、緩存擊穿
1、概念
某個 key 非常非常熱點，訪問非常的頻繁，高併發訪問的情況下，當這個 key在失效（可能expire過期了，也可能LRU淘汰了）的瞬間，大量的請求進來，這時候就擊穿了緩存，直接請求到了數據庫，一下子來這麼多，數據庫肯定受不了，這就叫緩存擊穿。某個key突然失效，然後這時候高併發來訪問這個key，結果緩存裏沒有，都跑到db了。
2、解決方案
- 熱點數據永不過期（看業務需求。不過很少有這種場景，一般都是比如搞活動或者大促的時候纔會存這些熱點數據，活動過後就需要到期，不會設置永不過期。），此方法簡單粗暴，不過還看具體需求。
- 分佈式鎖。來個請求後先鎖住，然後去db查，查到後再將數據set到redis裏。只有當redis裏getKey沒拿到數據需要請求db的時候才加鎖。不影響Redis裏有數據的時候處理高併發請求，也能保證db不會被打垮。
四、個人公衆號
微信公衆號【Java碼農社區】
