1.緩存雪崩
對于系統(tǒng) A，假設每天高峰期每秒 5000 個請求帕识，本來緩存在高峰期可以扛住每秒 4000 個請求泛粹，但是緩存機器意外發(fā)生了全盤宕機。緩存掛了肮疗，此時 1 秒 5000 個請求全部落數據庫晶姊，數據庫必然扛不住，它會報一下警伪货，然后就掛了们衙。此時，如果沒有采用什么特別的方案來處理這個故障碱呼，DBA 很著急蒙挑，重啟數據庫，但是數據庫立馬又被新的流量給打死了愚臀。
這就是緩存雪崩忆蚀。
解決方案如下：
事前：redis 高可用，主從+哨兵姑裂，redis cluster馋袜，避免全盤崩潰。
事中：本地 ehcache 緩存 + hystrix 限流&降級炭分，避免 MySQL 被打死桃焕。
事后：redis 持久化，一旦重啟捧毛，自動從磁盤上加載數據观堂，快速恢復緩存數據。
- 處理緩存雪崩簡單呀忧，在批量往Redis存數據的時候师痕，把每個Key的失效時間都加個隨機值就好了，這樣可以保證數據不會再同一時間大面積失效而账。
setRedis（key, value, time+Math.random()*10000）;
- 如果Redis是集群部署胰坟，將熱點數據均勻分布在不同的Redis庫中也能避免全部失效。
- 或者設置熱點數據永不過期泞辐，有更新操作就更新緩存就好了
用戶發(fā)送一個請求笔横，系統(tǒng) A 收到請求后竞滓，先查本地 ehcache 緩存，如果沒查到再查 redis吹缔。如果 ehcache 和 redis 都沒有商佑，再查數據庫，將數據庫中的結果厢塘，寫入 ehcache 和 redis 中茶没。
限流組件，可以設置每秒的請求晚碾，有多少能通過組件抓半，剩余的未通過的請求，怎么辦格嘁？走降級笛求！可以返回一些默認的值，或者友情提示讥蔽，或者空白的值涣易。
好處：
- 數據庫絕對不會死，限流組件確保了每秒只有多少個請求能通過冶伞。
- 只要數據庫不死新症，就是說，對用戶來說响禽，2/5 的請求都是可以被處理的徒爹。
- 只要有 2/5 的請求可以被處理，就意味著你的系統(tǒng)沒死芋类，對用戶來說隆嗅，可能就是點擊幾次刷不出來頁面，但是多點幾次侯繁，就可以刷出來一次胖喳。
2.緩存穿透
對于系統(tǒng)A，假設一秒 5000 個請求贮竟，結果其中 4000 個請求是黑客發(fā)出的惡意攻擊丽焊。
黑客發(fā)出的那 4000 個攻擊，緩存中查不到咕别，每次你去數據庫里查技健，也查不到。
緩存穿透就是指緩存和數據庫中都沒有的數據
舉個栗子惰拱。數據庫 id 是從 1 開始的雌贱，結果黑客發(fā)過來的請求 id 全部都是負數。這樣的話，緩存中不會有欣孤，請求每次都“視緩存于無物”馋没，直接查詢數據庫。這種惡意攻擊場景的緩存穿透就會直接把數據庫給打死导街。
解決方式:
- 每次系統(tǒng) A 從數據庫中只要沒查到披泪，就寫一個空值到緩存里去纤子，比如 set -999 UNKNOWN搬瑰。然后設置一個過期時間，這樣的話控硼，下次有相同的 key 來訪問的時候泽论，在緩存失效之前，都可以直接從緩存中取數據
- 在接口層增加校驗卡乾，比如用戶鑒權翼悴，參數做校驗，不合法的校驗直接return幔妨，比如id做基礎校驗鹦赎，id<=0直接攔截。
- 采用布隆過濾器（Bloom Filter） 這個也能很好的預防緩存穿透的發(fā)生误堡，他的原理就是利用高效的數據結構和算法快速判斷出你這個Key是否在數據庫中存在古话，不存在你return就好了，存在你就去查DB刷新KV再return锁施。
3.緩存擊穿
緩存擊穿:就是說某個 key 非常熱點陪踩，訪問非常頻繁，處于集中式高并發(fā)訪問的情況悉抵，當這個 key 在失效的瞬間肩狂，大量的請求就擊穿了緩存，直接請求數據庫姥饰，就像是在一道屏障上鑿開了一個洞傻谁。
解決方式:
- 可以將熱點數據設置為永遠不過期；
- 或者基于 redis or zookeeper 實現互斥鎖列粪，等待第一個請求構建完緩存之后审磁，再釋放鎖，進而其它請求才能通過該 key 訪問數據篱竭。
