如何處理緩存失效、緩存穿透、緩存併發等問題

 

緩存失效：

　　引發這個緣由的主要因素是高併發下，咱們通常設定一個緩存的過時時間時，可能有一些會設置5分鐘啊，10分鐘這些；併發很高時可能會出在某一個時間同時生成了不少的緩存，而且過時時間在同一時刻，這個時候就可能引起——當過時時間到後，這些緩存同時失效，請求所有轉發到DB，DB可能會壓力太重。

　　處理方法：

　　　　一個簡單方案就是將緩存失效時間分散開，不要因此緩存時間長度都設置成5分鐘或者10分鐘；好比咱們能夠在原有的失效時間基礎上增長一個隨機值，好比1-5分鐘隨機，這樣每個緩存的過時時間的重複率就會下降，就很難引起集體失效的事件。

   緩存失效時產生的雪崩效應，將全部請求所有放在數據庫上，這樣很容易就達到數據庫的瓶頸，致使服務沒法正常提供。儘可能避免這種場景的發生。

緩存穿透：

　　出現場景：指查詢一個必定不存在的數據，因爲緩存是不命中時被動寫的，而且出於容錯考慮，若是從存儲層查不到數據則不寫入緩存，這將致使這個不存在的數據每次請求都要到存儲層去查詢，失去了緩存的意義。

　　當在流量較大時，出現這樣的狀況，一直請求DB，很容易致使服務掛掉。

     處理方法：

　　　　方法1.在封裝的緩存SET和GET部分增長個步驟，若是查詢一個KEY不存在，就已這個KEY爲前綴設定一個標識KEY；之後再查詢該KEY的時候，先查詢標識KEY，若是標識KEY存在，就返回一個協定好的非false或者NULL值，而後APP作相應的處理，這樣緩存層就不會被穿透。固然這個驗證KEY的失效時間不能太長。

　　　　方法2.若是一個查詢返回的數據爲空（無論是數據不存在，仍是系統故障），咱們仍然把這個空結果進行緩存，但它的過時時間會很短，通常只有幾分鐘。

　　　　方法3.採用布隆過濾器，將全部可能存在的數據哈希到一個足夠大的bitmap中，一個必定不存在的數據會被這個bitmap攔截掉，從而避免了對底層存儲系統的查詢壓力。

緩存併發：　

　　出現場景：當網站併發訪問高，一個緩存若是失效，可能出現多個進程同時查詢DB，同時設置緩存的狀況，若是併發確實很大，這也可能形成DB壓力過大，還有緩存頻繁更新的問題。

　　處理方法：對緩存查詢加鎖，若是KEY不存在，就加鎖，而後查DB入緩存，而後解鎖；其餘進程若是發現有鎖就等待，而後等解鎖後返回數據或者進入DB查詢。