快取失效: 
  引起這個原因的主要因素是高併發下,我們一般設定一個快取的過期時間時,可能有一些會設定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查詢。