redis快取穿透、快取雪崩、熱點Key問題分析及解決方案
我們通常使用 快取 + 過期時間的策略來幫助我們加速介面的訪問速度，減少了後端負載，同時保證功能的更新。
快取穿透
快取系統，按照KEY去查詢VALUE,當KEY對應的VALUE一定不存在的時候並對KEY併發請求量很大的時候，就會對後端造成很大的壓力。
查詢一個必然不存在的資料。比如文章表，查詢一個不存在的id，每次都會訪問DB，如果有人惡意破壞，很可能直接對DB造成影響。
由於快取不命中，每次都要查詢持久層（回源），從而失去快取的意義。
解決方法
- 快取層快取空值
- 快取太多空值，佔用更多空間。（優化：給個空值過期時間）
- 儲存層更新程式碼了，快取層還是空值。（優化：後臺設定時主動刪除空值，並快取把值進去）
- 將資料庫中所有的查詢條件，放到 布隆過濾器 中。當一個查詢請求來臨的時候，先經過布隆過濾器進行檢查，如果請求存在這個條件中，那麼繼續執行，如果不在，直接丟棄。
注意事項：
使用布隆過濾器時，如果資料庫中有10000個條件，那麼布隆過濾器的容量size設定的要稍微比10000大一些，比如12000。
對於誤判率的設定，根據實際專案，以及硬體設施來具體決定。但是一定不能設定為0，並且誤判率設定的越小，雜湊函式跟陣列長度都會更多跟更長，那麼對硬體，記憶體中間的要求就會相應的高。
private static BloomFilter<Integer> bloomFilter = BloomFilter.create(Funnels.integerFunnel(), size, 0.0001); 有了size跟誤判率，那麼布隆過濾器就會產生相應的雜湊函式跟陣列。
綜上： 我們可以利用布隆過濾器，將redis快取擊穿控制在一個可容忍的範圍內。
快取雪崩(快取失效)
如果快取集中在一段時間內失效，發生大量的快取穿透，所有的查詢都落在資料庫上，造成了快取雪崩。
快取層宕掉後，流量會像奔逃的野牛一樣，打向後端儲存。
解決辦法
- 在快取失效後，通過加鎖或者佇列來控制讀資料庫寫快取的執行緒數量。比如對某個key只允許一個執行緒查詢資料和寫快取，其他執行緒等待；
- 可以通過快取reload機制，預先去更新快取，再即將發生大併發訪問前手動觸發載入快取；
- 不同的key，設定不同的過期時間，讓快取失效的時間點儘量均勻；
- 做二級快取，或者雙快取策略：
- A1為原始快取，A2為拷貝快取；
- A1失效時，可以訪問A2，A1快取失效時間設定為短期，A2設定為長期。
熱點key
- 這個key是一個熱點key（例如一個重要的新聞，一個熱門的八卦新聞等等），所以這種key訪問量可能非常大。
- 快取的構建是需要一定時間的。（可能是一個複雜計算，例如複雜的sql、多次IO、多個依賴(各種介面)等等）
於是就會出現一個致命問題：在快取失效的瞬間，有大量執行緒來構建快取（見下圖），造成後端負載加大，甚至可能會讓系統崩潰 。
解決辦法
-
使用互斥鎖(mutex key)：這種解決方案思路比較簡單，就是隻讓一個執行緒構建快取，其他執行緒等待構建快取的執行緒執行完，重新從快取獲取資料就可以了；
-
"提前"使用互斥鎖(mutex key)：在value內部設定1個超時值(timeout1), timeout1比實際的memcache timeout(timeout2)小。當從cache讀取到timeout1發現它已經過期時候，馬上延長timeout1並重新設定到cache。然後再從資料庫載入資料並設定到cache中；
-
"永遠不過期"：
這裡的“永遠不過期”包含兩層意思
- 從redis上看，確實沒有設定過期時間，這就保證了，不會出現熱點key過期問題，也就是“物理”不過期；
- 從功能上看，如果不過期，那不就成靜態的了嗎？所以我們把過期時間存在key對應的value裡，如果發現要過期了，通過一個後臺的非同步執行緒進行快取的構建，也就是“邏輯”過期
-
資源保護：可以做資源的隔離保護主執行緒池，如果把這個應用到快取的構建也未嘗不可。
四種方案對比
作為一個併發量較大的網際網路應用，我們的目標有3個:
- 加快使用者訪問速度，提高使用者體驗。
- 降低後端負載，保證系統平穩。
- 保證資料“儘可能”及時更新（要不要完全一致，取決於業務，而不是技術。）
所以第二節中提到的四種方法，可以做如下比較，還是那就話：沒有最好，只有最合適。
| 解決方案 | 優點 | 缺點 |
|---|---|---|
| 簡單分散式鎖(Tim yang) | 1. 思路簡單<br />2. 保證一致性 | 1. 程式碼複雜度增大<br />2. 存在死鎖的風險<br />3. 存線上程池阻塞的風險 |
| 加另外一個過期時間(Tim yang) | 1. 保證一致性 | 同上 |
| 不過期(本文) | 1. 非同步構建快取，不會阻塞執行緒池 | 1. 不保證一致性。<br />2. 程式碼複雜度增大(每個value都要維護一個timekey)。<br />3. 佔用一定的記憶體空間(每個value都要維護一個timekey)。 |
| 資源隔離元件hystrix(本文) | 1. hystrix技術成熟，有效保證後端。<br />2. hystrix監控強大。 | 1. 部分訪問存在降級策略。 |
總結
- 熱點key + 過期時間 + 複雜的構建快取過程 => mutex key問題
- 構建快取一個執行緒做就可以了。
- 四種解決方案：沒有最佳只有最合適。