一. 緩存雪崩

　　緩存雪崩我們可以簡單的理解為：由于原有緩存失效，新緩存未到期間所有原本應該訪問緩存的請求都去查詢數據庫了，而對數據庫 CPU 和內存造成巨大壓力，嚴重的會造成數據庫宕機。從而形成一系列連鎖反應，造成整個系統崩潰。

　　一般有三種處理辦法：

　　1. 一般并發量不是特別多的時候，使用最多的解決方案是加鎖排隊。

　　2. 給每一個緩存數據增加相應的緩存標記，記錄緩存的是否失效，如果緩存標記失效，則更新數據緩存。

　　3. 為 key 設置不同的緩存失效時間。

　　二. 緩存穿透

　　緩存穿透是指用戶查詢數據，在數據庫沒有，自然在緩存中也不會有。這樣就導致用戶查詢的時候，在緩存中找不到，每次都要去數據庫再查詢一遍，然后返回空(相當于進行了兩次無用的查詢)。這樣請求就繞過緩存直接查數據庫，這也是經常提的緩存命中率問題。 有很多種方法可以有效地解決緩存穿透問題，最常見的則是采用布隆過濾器，將所有可能存在的數據哈希到一個足夠大的bitmap中，一個一定不存在的數據會被這個bitmap攔截掉，從而避免了對底層存儲系統的查詢壓力。另外也有一個更為簡單粗暴的方法，如果一個查詢返回的數據為空(不管是數據不存在，還是系統故障)，我們仍然把這個空結果進行緩存，但它的過期時間會很短，最長不超過五分鐘。 通過這個直接設置的默認值存放到緩存，這樣第二次到緩沖中獲取就有值了，而不會繼續訪問數據庫。

　　三. 緩存預熱

　　緩存預熱就是系統上線后，將相關的緩存數據直接加載到緩存系統。這樣就可以避免在用戶請求的時候，先查詢數據庫，然后再將數據緩存的問題!用戶直接查詢事先被預熱的緩存數據!

　　四. 緩存更新

　　緩存更新除了緩存服務器自帶的緩存失效策略之外(Redis 默認的有 6 中策略可供選擇)，我們還可以根據具體的業務需求進行自定義的緩存淘汰，常見的策略有兩種：

　　(1) 定時去清理過期的緩存;

　　(2) 當有用戶請求過來時，再判斷這個請求所用到的緩存是否過期，過期的話就去底層系統得到新數據并更新緩存。

　　五. 緩存降級 當訪問量劇增、服務出現問題(如響應時間慢或不響應)或非核心服務影響到核心流程的性能時，仍然需要保證服務還是可用的，即使是有損服務。系統可以根據一些關鍵數據進行自動降級，也可以配置開關實現人工降級。降級的最終目的是保證核心服務可用，即使是有損的。而且有些服務是無法降級的 (如加入購物車、結算)。