1 快取失效

　　引起這個原因的主要因素是高併發下，一般設定一個快取的過期時間時，併發很高時可能會出在某一個時間同時生成很多的快取，並且過期時間在同一時刻，這個時候就可能引發——當過期時間到後，這些快取同時失效，請求全部轉發到DB，DB可能會壓力過重。
　　處理方法： 將快取失效時間分散開，不要所以快取時間長度都設定成特定時長；比如在原有的失效時間基礎上增加一個隨機值，比如1-5分鐘隨機，這樣每一個快取的過期時間的重複率就會降低，就很難引發集體失效的事件。 快取失效時產生的雪崩效應，將所有請求全部放在資料庫上，這樣很容易就達到資料庫的瓶頸，導致服務無法正常提供。儘量避免這種場景的發生。

2 快取穿透
　　出現場景：指查詢一個一定不存在的資料，由於快取是不命中時被動寫的，並且出於容錯考慮，如果從儲存層查不到資料則不寫入快取，這將導致這個不存在的資料每次請求都要到儲存層去查詢，失去了快取的意義。
　　當在流量較大時，出現這樣的情況，一直請求DB，很容易導致服務掛掉。
　　處理方法：
　　方法1.在封裝的快取SET和GET部分增加個步驟，如果查詢一個KEY不存在，就已這個KEY為字首設定一個標識KEY；以後再查詢該KEY的時候，先查詢標識KEY，如果標識KEY存在，就返回一個協定好的非false或者NULL值，然後APP做相應的處理，這樣快取層就不會被穿透。當然這個驗證KEY的失效時間不能太長，當db有值時，利用訊息服務清除快取空資料。
　　方法2.如果一個查詢返回的資料為空（不管是資料不存在，還是系統故障），我們仍然把這個空結果進行快取，但它的過期時間會很短，一般只有幾分鐘。
　　方法3.採用布隆過濾器，將所有可能存在的資料雜湊到一個足夠大的bitmap中，一個一定不存在的資料會被這個bitmap攔截掉，從而避免了對底層儲存系統的查詢壓力。

3 快取併發
　　出現場景：當網站併發訪問高，一個快取如果失效，可能出現多個程序同時查詢DB，同時設定快取的情況，如果併發確實很大，這也可能造成DB壓力過大，還有快取頻繁更新的問題。
　　處理方法：對快取查詢加鎖，如果KEY不存在，就加鎖，然後查DB入快取，然後解鎖；其他程序如果發現有鎖就等待，然後等解鎖後返回資料或者進入DB查詢。

4 快取雪崩
　　出現場景：由於快取層承載著大量請求，有效的保護了儲存層，但是如果快取層由於某些原因整體不能提供服務，於是所有的請求都會達到儲存層，儲存層的呼叫量會暴增，造成儲存層也會掛掉的情況。 快取雪崩的英文原意是 stampeding herd（奔逃的野牛），指的是快取層宕掉後，流量會像奔逃的野牛一樣，打向後端儲存。
　　處理方法：快取高可用，Redis Sentinel 和 Redis Cluster 實現