一、緩存穿透
在項目中使用緩存通常都是APP先檢查緩存中是否命中，如果命中直接返回緩存內容；如果不命中就直接查詢數據庫然後回寫緩存並返回結果。此時如果查詢某個數據在緩存中一直不存在，就會造成每一次請求都查詢DB，這樣緩存就失去了意義，在流量大時，DB可能就會掛掉。如果碰到這樣的問題可以在封裝的緩存SET和GET部分增加個步驟，如果查詢一個KEY不存在，就以這個KEY爲前綴設定一個標識KEY；以後再查詢該KEY的時候，先查詢標識KEY，如果標識KEY存在，就返回一個協定好的非FALSH或者NULL值，然後APP做相應的處理，這樣緩存層就不會被穿透。當然這個驗證KEY的失效時間不能太長。
二、緩存併發
有時候如果網站併發訪問高，一個緩存如果失效，可能出現多個進程同時查詢DB，同時回寫緩存的情況；如果併發確實很大，可能造成DB壓力過大，還有緩存頻繁更新的問題。我現在的想法是再APP中對緩存查詢加鎖，如果KEY不存在，就加鎖，然後查DB入緩存，然後解鎖；其他進程如果發現有鎖就等待，然後等解鎖後返回數據或者進入DB查詢。
三、緩存失效
引起這個問題的主要原因還是高併發的時候，平時我們設定一個緩存的過期時間時，可能有一些會設置5分鐘，10分鐘等；併發很高時可能會出在某一個時間同時生成了很多的緩存，並且過期時間都一樣，這個時候就可能引發一當過期時間到後，這些緩存同時失效，請求全部轉發到DB，DB可能會壓力過重。一個簡單方案就是將緩存失效時間分散開，比如可以在原有的失效時間基礎上增加一個隨機值，比如1-5分鐘隨機，這樣每一個緩存的過期時間的重複率就會降低，就很難引發集體失效的事件。