.

我們通常使用 快取 + 過期時間的策略來幫助我們加速介面的訪問速度,減少了後端負載,同時保證功能的更新。

快取穿透

快取系統,按照KEY去查詢VALUE,KEY對應的VALUE一定不存在的時候並對KEY併發請求量很大的時候,就會對後端造成很大的壓力。

查詢一個必然不存在的資料。比如文章表,查詢一個不存在的id,每次都會訪問DB,如果有人惡意破壞,很可能直接對DB造成影響。

由於快取不命中,每次都要查詢持久層(回源),從而失去快取的意義。

解決方法

  1. 快取層快取空值
    • 快取太多空值,佔用更多空間。(優化:給個空值過期時間)
    • 儲存層更新程式碼了,快取層還是空值。(優化:後臺設定時主動刪除空值,並快取把值進去)
  2. 將資料庫中所有的查詢條件,放到 布隆過濾器 中。當一個查詢請求來臨的時候,先經過布隆過濾器進行檢查,如果請求存在這個條件中,那麼繼續執行,如果不在,直接丟棄。

注意事項:

​ 使用布隆過濾器時,如果資料庫中有10000個條件,那麼布隆過濾器的容量size設定的要稍微比10000大一些,比如12000。

​ 對於誤判率的設定,根據實際專案,以及硬體設施來具體決定。但是一定不能設定為0,並且誤判率設定的越小,雜湊函式跟陣列長度都會更多跟更長,那麼對硬體,記憶體中間的要求就會相應的高。

private static BloomFilter<Integer> bloomFilter = BloomFilter.create(Funnels.integerFunnel(), size, 0.0001);

​ 有了size跟誤判率,那麼布隆過濾器就會產生相應的雜湊函式跟陣列。

綜上: 我們可以利用布隆過濾器,將redis快取擊穿控制在一個可容忍的範圍內。

快取雪崩(快取失效)

如果快取集中在一段時間內失效,發生大量的快取穿透,所有的查詢都落在資料庫上,造成了快取雪崩。

快取層宕掉後,流量會像奔逃的野牛一樣,打向後端儲存

解決辦法

  1. 在快取失效後,通過加鎖或者佇列來控制讀資料庫寫快取的執行緒數量。比如對某個key只允許一個執行緒查詢資料和寫快取,其他執行緒等待;
  2. 可以通過快取reload機制,預先去更新快取,再即將發生大併發訪問前手動觸發載入快取;
  3. 不同的key,設定不同的過期時間,讓快取失效的時間點儘量均勻;
  4. 做二級快取,或者雙快取策略:
    • A1為原始快取,A2為拷貝快取;
    • A1失效時,可以訪問A2,A1快取失效時間設定為短期,A2設定為長期。

熱點key

  • 這個key是一個熱點key(例如一個重要的新聞,一個熱門的八卦新聞等等),所以這種key訪問量可能非常大。
  • 快取的構建是需要一定時間的。(可能是一個複雜計算,例如複雜的sql、多次IO、多個依賴(各種介面)等等)

於是就會出現一個致命問題:在快取失效的瞬間,有大量執行緒來構建快取(見下圖),造成後端負載加大,甚至可能會讓系統崩潰 。

解決辦法

  1. 使用互斥鎖(mutex key):這種解決方案思路比較簡單,就是隻讓一個執行緒構建快取,其他執行緒等待構建快取的執行緒執行完,重新從快取獲取資料就可以了;

  2. "提前"使用互斥鎖(mutex key):在value內部設定1個超時值(timeout1), timeout1比實際的memcache timeout(timeout2)小。當從cache讀取到timeout1發現它已經過期時候,馬上延長timeout1並重新設定到cache。然後再從資料庫載入資料並設定到cache中;

  3. "永遠不過期":

    這裡的“永遠不過期”包含兩層意思

    • 從redis上看,確實沒有設定過期時間,這就保證了,不會出現熱點key過期問題,也就是“物理”不過期;
    • 從功能上看,如果不過期,那不就成靜態的了嗎?所以我們把過期時間存在key對應的value裡,如果發現要過期了,通過一個後臺的非同步執行緒進行快取的構建,也就是“邏輯”過期
  4. 資源保護:可以做資源的隔離保護主執行緒池,如果把這個應用到快取的構建也未嘗不可。

四種方案對比

作為一個併發量較大的網際網路應用,我們的目標有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問題
  • 構建快取一個執行緒做就可以了。
  • 四種解決方案:沒有最佳只有最合適。

參考文獻: