使用Redis作爲緩存到時候，經常會出現緩存雪崩、擊穿和穿透的問題。這幾個經典問題是什麼？又該如何解決？
緩存雪崩
緩存雪崩是大量Key同時失效，對這些Key的請求會到數據庫上，同樣會導致數據庫壓力過大甚至掛掉。
電商平臺一般會對數據進行緩存，如果所有首頁的Key失效時間都是12小時，中午12點刷新，零點有個秒殺活動大量用戶涌入，假設當時每秒 6000 個請求，本來緩存在可以扛住每秒 5000 個請求，但是緩存當時所有的Key都失效了。此時 1 秒 6000 個請求全部落數據庫，數據庫必然扛不住，會報警，而DBA反應不過來可能會重啓數據庫，但是數據庫立馬又被新的流量給打死了。
解決方案：讓Key的失效時間分散開，可以在統一的失效時間上再加一個隨機值，或者使用更高級的算法分散失效時間。
緩存穿透
程序在處理緩存時，一般是先從緩存查詢，如果緩存沒有這個key獲取爲null，則會從數據庫中查詢，並設置到緩存中去。那查詢一個一定不存在的數據值，需要從數據庫查詢，查不到數據則不寫入緩存，這將導致這個不存在的數據每次請求都要到數據庫去查詢，造成緩存穿透。
簡單來說，就是發起了一個查詢操作，這個值緩存和數據庫中都沒有，這樣就會來回的執行這一套流程，讀取redis，發現沒有然後連接數據庫，發現也沒有，從而造成緩存穿透。
解決方法：可以在系統層面加一層過濾，將系統認爲非法的key進行一次攔截，直接返回給客戶端錯誤信息。
緩存擊穿
緩存擊穿是針對緩存和數據庫中都沒有的數據。當Key失效後突然涌入大量的請求，都會請求到DB，導致數據庫壓力過大而崩潰。
這個問題的解決辦法就是：
1、設置熱點Key，自動檢測熱點Key，將熱點Key的過期時間加大或者設置爲永不過期，或者設置爲邏輯上永不過期。
2、加互斥鎖。當發現沒有命中Redis，去查數據庫的時候，在執行更新緩存的操作上加鎖，誰拿到鎖誰去更新，同時在拿到鎖之後先從緩存再獲取一次如果有就返回，沒有就查庫然後更新。（雙重校驗）