1. 什麼是緩存雪崩？怎麼解決？
通常，我們會使用緩存用於緩衝對 DB 的衝擊，如果緩存宕機，所有請求將直接打在 DB，造成 DB 宕機——從而導致整個系統宕機。
如何解決呢？
2 種策略（同時使用）：
2. 什麼是緩存穿透？怎麼解決？
解釋 1：緩存查詢一個沒有的 key，同時資料庫也沒有，如果黑客大量的使用這種方式，那麼就會導致 DB 宕機。
解決方案：我們可以使用一個默認值來防止，例如，當訪問一個不存在的 key，然後再去訪問資料庫，還是沒有，那麼就在緩存里放一個占位符，下次來的時候，檢查這個占位符，如果發生時占位符，就不去資料庫查詢了，防止 DB 宕機。
解釋 2：大量請求查詢一個剛剛失效的 key，導致 DB 壓力倍增，可能導致宕機，但實際上，查詢的都是相同的數據。
解決方案：可以在這些請求代碼加上雙重檢查鎖。但是那個階段的請求會變慢。不過總比 DB 宕機好。
3. 什麼是緩存並發競爭？怎麼解決？
解釋：多個客戶端寫一個 key，如果順序錯了，數據就不對了。但是順序我們無法控制。
解決方案：使用分布式鎖，例如 zk，同時加入數據的時間戳。同一時刻，只有搶到鎖的客戶端才能寫入，同時，寫入時，比較當前數據的時間戳和緩存中數據的時間戳。
4.什麼是緩存和資料庫雙寫不一致？怎麼解決？
解釋：連續寫資料庫和緩存，但是操作期間，出現並發了，數據不一致了。
通常，更新緩存和資料庫有以下幾種順序：
三種方式的優劣來看一下：
先更新資料庫，再更新緩存。
這麼做的問題是：當有 2 個請求同時更新數據，那麼如果不使用分布式鎖，將無法控制最後緩存的值到底是多少。也就是並發寫的時候有問題。
先刪緩存，再更新資料庫。
這麼做的問題：如果在刪除緩存後，有客戶端讀數據，將可能讀到舊數據，並有可能設置到緩存中，導致緩存中的數據一直是老數據。
有 2 種解決方案：
總的來講，比較麻煩。
先更新資料庫，再刪除緩存
這個實際是常用的方案，但是有很多人不知道，這裡介紹一下，這個叫 Cache Aside Pattern，老外發明的。如果先更新資料庫，再刪除緩存，那麼就會出現更新資料庫之前有瞬間數據不是很及時。
同時，如果在更新之前，緩存剛好失效了，讀客戶端有可能讀到舊值，然後在寫客戶端刪除結束後再次設置了舊值，非常巧合的情況。
有 2 個前提條件：緩存在寫之前的時候失效，同時，在寫客戶度刪除操作結束後，放置舊數據 —— 也就是讀比寫慢。設置有的寫操作還會鎖表。
所以，這個很難出現，但是如果出現了怎麼辦？使用雙刪！！！記錄更新期間有沒有客戶端讀資料庫，如果有，在更新完資料庫之後，執行延遲刪除。
還有一種可能，如果執行更新資料庫，準備執行刪除緩存時，服務掛了，執行刪除失敗怎麼辦？？？
end：如果你覺得本文對你有幫助的話，記得關注點贊轉發，你的支持就是我更新動力。