redis穿透
什么是redis穿透？
1、查詢一個一定不存在的數據，由於緩存是不命中時被動寫的，並且出於容錯考慮，如果從存儲層查不到數據則不寫入緩存
2、這將導致這個不存在的數據每次請求都要到存儲層去查詢，失去了緩存的意義
3、在流量大時，可能DB就掛掉了，要是有人利用不存在的key頻繁攻擊我們的應用，這就是漏洞。
發生場景：
對於系統A，假設一秒 5000 個請求，結果其中 4000 個請求是黑客發出的惡意攻擊。
黑客發出的那 4000 個攻擊，緩存中查不到，每次你去數據庫里查，也查不到。
舉個栗子。數據庫 id 是從 1 開始的，結果黑客發過來的請求 id 全部都是負數。這樣的話，緩存中不會有，請求每次都“視緩存於無物”，直接查詢數據庫。這種惡意攻擊場景的緩存穿透就會直接把數據庫給打死。
解決方案
1、有很多種方法可以有效地解決緩存穿透問題，最常見的則是采用布隆過濾器，將所有可能存在的數據哈希到一個足夠大的bitmap中，一個一定不存在的數據會被這個bitmap攔截掉，從而避免了對底層存儲系統的查詢壓力。
2、另外也有一個更為簡單粗暴的方法，如果一個查詢返回的數據為空（不管是數據不存在，還是系統故障），我們仍然把這個空結果進行緩存，但它的過期時間會很短，最長不超過五分鍾。
redis雪崩：
什么是redis雪崩？
1、緩存中大批量熱點數據過期后系統涌入大量查詢請求
2、因為大部分數據在Redis層已經失效，請求滲透到數據庫層
3、大批量請求猶如洪水一般涌入，引起數據庫壓力造成查詢堵塞甚至宕機。
發生場景
對於系統 A，假設每天高峰期每秒 5000 個請求，本來緩存在高峰期可以扛住每秒 4000 個請求，但是緩存機器意外發生了全盤宕機，緩存掛了。
此時 1 秒 5000 個請求全部落數據庫，數據庫必然扛不住，它會報一下警，然后就掛了。
此時，如果沒有采用什么特別的方案來處理這個故障，DBA 很着急，重啟數據庫，但是數據庫立馬又被新的流量給打死了。
解決方案
1、事前：redis 高可用，主從+哨兵，redis cluster，避免全盤崩潰
2、事中：本地 ehcache 緩存 + hystrix 限流&降級，避免 MySQL 被打死。
3、事后：redis 持久化，一旦重啟，自動從磁盤上加載數據，快速恢復緩存數據。
4、用戶發送一個請求，系統 A 收到請求后，先查本地 ehcache 緩存，如果沒查到再查 redis。如果 ehcache 和 redis 都沒有，再查數據庫，將數據庫中的結果，寫入 ehcache 和 redis 中。
5、 限流組件，可以設置每秒的請求，有多少能通過組件，剩余的未通過的請求，怎么辦？走降級！可以返回一些默認的值，或者友情提示，或者空白的值。這樣可以保證數據庫絕對不會死，限流組件確保了每秒只有多少個請求能通過。 -只要數據庫不死，就是說，對用戶來說，2/5 的請求都是可以被處理的。 - 只要有 2/5 的請求可以被處理，就意味着你的系統沒死，對用戶來說，可能就是點擊幾次刷不出來頁面，但是多點幾次，就可以刷出來一次。
redis擊穿
什么是redis的擊穿
1、就是說某個 key 非常熱點，訪問非常頻繁，處於集中式高並發訪問的情況
2、當這個 key 在失效的瞬間，大量的請求就擊穿了緩存，直接請求數據庫，就像是在一道屏障上鑿開了一個洞。
3、擊穿和緩存雪崩的區別在於擊穿針對某一key緩存，雪崩則是很多key
發生場景
秒殺現場，在同一時間高頻訪問某一數據，並且當前數據正好過期。
解決方案
1、可以將熱點數據設置為永遠不過期
2、實現互斥鎖，等待第一個請求構建完緩存之后，再釋放鎖，進而其它請求才能通過該 key 訪問數據。