分佈式緩存：緩存雪崩+緩存穿透+緩存預熱+緩存更新+緩存降級

緩存雪崩
緩存雪崩咱們能夠簡單的理解爲：因爲原有緩存失效，新緩存未到期間全部本來應該訪問緩存的請求都去查詢數據庫了，而對數據庫 CPU 和內存形成巨大壓力，嚴重的會形成數據庫宕機。從而造成一系列連鎖反應，形成整個系統崩潰。通常有三種處理辦法：

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

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

3. 爲 key 設置不一樣的緩存失效時間。

緩存穿透
緩存穿透是指用戶查詢數據，在數據庫沒有，天然在緩存中也不會有。這樣就致使用戶查詢的時候，在緩存中找不到，每次都要去數據庫再查詢一遍，而後返回空（至關於進行了兩次無用的查詢）。這樣請求就繞過緩存直接查數據庫，這也是常常提的緩存命中率問題。

有不少種方法能夠有效地解決緩存穿透問題，最多見的則是採用布隆過濾器，將全部可能存在的數據哈希到一個足夠大的 bitmap 中，一個必定不存在的數據會被這個 bitmap 攔截掉，從而避免了對底層存儲系統的查詢壓力。另外也有一個更爲簡單粗暴的方法，若是一個查詢返回的數據爲空（無論是數據不存在，仍是系統故障），咱們仍然把這個空結果進行緩存，但它的過時時間會很短，最長不超過五分鐘。

經過這個直接設置的默認值存放到緩存，這樣第二次到緩衝中獲取就有值了，而不會繼續訪問數據庫。

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

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

（1）定時去清理過時的緩存；

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

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