一.緩存雪崩，緩存穿透，緩存擊穿 1.緩存穿透： key對應的數據在數據源并不存在，每次針對此key的請求從緩存獲取不到，請求都會到數據源，從而可能壓垮數據源。比如用一個不存在的用戶id獲取用戶信息，不論緩存還是數據庫都沒有，若黑客利用此漏洞進行攻擊可能壓垮數據庫 解決方案（最粗暴的）： 如果一個查詢返回的數據為空（不管是數據不存在，還是系統故障），我們仍然把這個空結果進行緩存，但它的過期時間會很短，最長不超過五分鐘 缺點：如果key數量巨大且分散無任何規律，就會浪費大量緩存空間，并且不能抗住瞬時流量沖擊 2.緩存擊穿（#熱點key）： key對應的數據存在，但在redis中過期，此時若有大量并發請求過來，這些請求發現緩存過期一般都會從后端DB加載數據并回設到緩存，這個時候大并發的請求可能會瞬間把后端DB壓垮 解決方案： 業界比較常用的做法，是使用mutex。簡單地來說，就是在緩存失效的時候（判斷拿出來的值為空），不是立即去load db，而是先使用緩存工具的某些帶成功操作返回值的操作（比如Redis的SETNX或者Memcache的ADD）去set一個mutex key，當操作返回成功時，再進行load db的操作并回設緩存；否則，就重試整個get緩存的方法。 3.緩存雪崩： 當緩存服務器重啟或者大量緩存集中在某一個時間段失效，這樣在失效的時候，也會給后端系統(比如DB)帶來很大壓力 解決方案： 使用鎖或隊列、設置過期標志更新緩存、為key設置不同的緩存失效時間，還有一種被稱為“二級緩存”的解決方法； 方案：設置過期標志更新緩存 做緩存標記，記錄緩存數據是否過期；標記緩存時間30分鐘，數據緩存設置為60分鐘。這樣，當緩存標記key過期后，實際緩存還能把舊數據返回給調用端，直到另外的線程在后臺更新完成后，才會返回新緩存 方案： 雙層緩存策略 C1為原始緩存，C2為拷貝緩存，C1失效時，可以訪問C2，C1緩存失效時間設置為短期，C2設置為長期 4.總結  二.緩存與數據庫雙寫不一致 （1）只讀緩存(?**`Cache Aside`?****模式)**  總結出，?當不存在并發的情況使用重試機制（消息隊列使用），當存在高并發的情況，使用延遲雙刪除(在第一次刪除后，睡眠一定時間后，再進行刪除) （2）讀寫緩存（Read/Write-Throug、Write Behind模式 ）  總結出，當不存在并發的情況使用重試機制（消息隊列使用），當存在高并發的情況，使用分布鎖