緩存穿透，緩存擊穿，緩存雪崩解決方案分析

緩存穿透

• 緩存穿透是指查詢一個必定不存在的數據
  • 因爲緩存是不命中時被動寫的，
  • 而且出於容錯考慮，若是從存儲層查不到數據則不寫入緩存，
  • 這將致使這個不存在的數據每次請求都要到存儲層去查詢，失去了緩存的意義。
• 在流量大時，可能DB就掛掉了，
  • 要是有人利用不存在的key頻繁攻擊咱們的應用，這就是漏洞。

• 解決方案

  • 最多見的則是採用布隆過濾器
    • 將全部可能存在的數據哈希到一個足夠大的bitmap中，
    • 一個必定不存在的數據會被 這個bitmap攔截掉，
    • 從而避免了對底層存儲系統的查詢壓力。
  • 另外也有一個更爲簡單粗暴的方法

    • 若是一個查詢返回的數據爲空（不論是數 據不存在，仍是系統故障），

    • 咱們仍然把這個空結果進行緩存，但它的過時時間會很短，最長不超過五分鐘

緩存雪崩

• 緩存雪崩是指在咱們設置緩存時採用了相同的過時時間，
• 致使緩存在某一時刻同時失效，請求所有轉發到DB，DB瞬時壓力太重雪崩。

• 解決方案

  • 緩存失效時的雪崩效應對底層系統的衝擊很是可怕。
    • 大多數系統設計者考慮用加鎖或者隊列的方式保證緩存的單線 程（進程）寫，
    • 從而避免失效時大量的併發請求落到底層存儲系統上。
  • 這裏分享一個簡單方案就時講緩存失效時間分散開，
    • 好比咱們能夠在原有的失效時間基礎上增長一個隨機值，好比1-5分鐘隨機，
    • 這樣每個緩存的過時時間的重複率就會下降，就很難引起集體失效的事件
  • 作二級緩存，一級緩存未查詢到數據，則從二級緩存查詢

緩存擊穿

• 對於一些設置了過時時間的key，若是這些key可能會在某些時間點被超高併發地訪問，是一種很是「熱點」的數據。
  • 這個時候，須要考慮一個問題：
    • 緩存被「擊穿」的問題，這個和緩存雪崩的區別在於這裏針對某一key緩存，前者則是不少key。
• 緩存在某個時間點過時的時候，
  • 剛好在這個時間點對這個Key有大量的併發請求過來，
  • 這些請求發現緩存過時通常都會從後端DB加載數據並回設到緩存，
  • 這個時候大併發的請求可能會瞬間把後端DB壓垮。

• 解決方案

  • ​​​​​​​一、使用互斥鎖(mutex key)
    • ​​​​​​​好比Redis的SETNX或者Memcache的ADD）去set一個mutex key，
      • 當操做返回成功時，再進行load db的操做並回設緩存；
      • 不然，就重試整個get緩存的方法。

  • 二、"提早"使用互斥鎖(mutex key)：

    • ​​​​​​​在value內部設置1個超時值(timeout1),
      • timeout1比實際的memcache timeout(timeout2)小。
      • 當從cache讀取到timeout1發現它已通過期時候，立刻延長timeout1並從新設置到cache。
      • 而後再從數據庫加載數據並設置到cache中

  • 三、"永遠不過時"：

    • ​​​​​​​從redis上看，確實沒有設置過時時間，
      • 這就保證了，不會出現熱點key過時問題，
      • 也就是「物理」不過時。
    • 從功能上看，若是不過時，那不就成靜態的了嗎？
      • 因此咱們把過時時間存在key對應的value裏，
      • 若是發現要過時了，經過一個後臺的異步線程進行緩存的構建，也就是「邏輯」過時
    • 從實戰看，這種方法對於性能很是友好，
      • 惟一不足的就是構建緩存時候，
        • 其他線程(非構建緩存的線程)可能訪問的是老數據，
        • 可是對於通常的互聯網功能來講這個仍是能夠忍受。

  • 四、資源保護：

    • ​​​​​​​採用netflix的hystrix，
    • 能夠作資源的隔離保護主線程池，
    • 若是把這個應用到緩存的構建也何嘗不可。

四種解決方案：沒有最佳只有最合適

• ​​​​​​​