一、快取雪崩

由於原有快取失效，新快取未到期間，比如我們設定快取時採用了相同的過期時間，在同一時刻出現大面積的快取過期，所有原本應該訪 問快取的請求都去查詢資料庫了，而對資料庫CPU和記憶體造成巨大壓力，嚴重的會造成資料庫宕機。從而形成一系列連鎖反應，造成整個系統崩潰。

解決辦法：

（1） 大多數系統設計者考慮用加鎖（ 最多的解決方案）或者使用佇列的方式保證來保證不會有大量的執行緒對資料庫一次性進行讀寫，從而避免失效時大量的併發請求落到底層儲存系統上。

（2）還有一個簡單方案就時將快取失效時間分散開。

二、快取穿透

快取穿透是指使用者查詢資料，在資料庫沒有，自然在快取中也不會有。這樣就導致使用者查詢的時候，在 快取中找不到，每次都要去資料庫再查詢一遍，然後返回空（相當於進行了兩次無用的查詢）。這樣請求就繞過快取直接查資料庫，這也是經常提的快取命中率問題。

解決辦法

（1）最常見的則是採用布隆過濾器，將所有可能存在的資料雜湊到一個足夠大的bitmap中，一個一定不存在的資料會被這個bitmap攔截掉，從而避免了對底層儲存系統的查詢壓力。

（2）另外也有一個更為簡單粗暴的方法，如果一個查詢返回的資料為空（不管是資料不存在，還是系統故 障），我們仍然把這個空結果進行快取，但它的過期時間會很短，最長不超過五分鐘。通過這個直接設 置的預設值存放到快取，這樣第二次到緩衝中獲取就有值了，而不會繼續訪問資料庫，這種辦法最簡單粗暴。

思考

5TB的硬碟上放滿了資料，請寫一個演算法將這些資料進行排重。如果這些資料是一些32bit大小的資料該 如何解決？如果是64bit的呢？

對於空間的利用到達了一種極致，那就是Bitmap和布隆過濾器(Bloom Filter)。

Bitmap： 典型的就是雜湊表；缺點是Bitmap對於每個元素只能記錄1bit資訊，如果還想完成額外的功能，恐怕只能靠犧牲更多的空 間、時間來完成了。

布隆過濾器（推薦）

就是引入了k(k>1)k(k>1)個相互獨立的雜湊函式，保證在給定的空間、誤判率下，完成元素判重的過 程。

它的優點是空間效率和查詢時間都遠遠超過一般的演算法，缺點是有一定的誤識別率和刪除困難。 Bloom-Filter演算法的核心思想就是利用多個不同的Hash函式來解決“衝突”。 Hash存在一個衝突（碰撞）的問題，用同一個Hash得到的兩個URL的值有可能相同。為了減少衝突， 我們可以多引入幾個Hash，如果通過其中的一個Hash值我們得出某元素不在集合中，那麼該元素肯定 不在集合中。只有在所有的Hash函式告訴我們該元素在集合中時，才能確定該元素存在於集合中。這便是Bloom-Filter的基本思想。

Bloom-Filter一般用於在大資料量的集合中判定某元素是否存在。

三、快取預熱

快取預熱這個應該是一個比較常見的概念，相信很多人都應該可以很容易的理解，快取預熱就是系統上線後，將相關的快取資料直接載入到快取系統。這樣就可以避免在使用者請求的時候，先查詢資料庫，然後再將資料快取的問題！使用者直接查詢事先被預熱的快取資料

解決辦法

（1）直接寫個快取重新整理頁面，上線時手工操作下；

（2）資料量不大，可以在專案啟動的時候自動進行載入；

（3）定時重新整理快取；

四、快取更新

除了快取伺服器自帶的快取失效策略之外（Redis預設的有6中策略可供選擇），我們還可以根據具體的 業務需求進行自定義的快取淘汰，常見的策略有兩種：

（1）定時去清理過期的快取；

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

兩者各有優劣，第一種的缺點是維護大量快取的key是比較麻煩的，第二種的缺點就是每次使用者請求過來都要判斷快取失效，邏輯相對比較複雜！具體用哪種方案，大家可以根據自己的應用場景來權衡。

五、快取降級

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

以參考日誌級別設定預案：

（1）一般：比如有些服務偶爾因為網路抖動或者服務正在上線而超時，可以自動降級；

（2）警告：有些服務在一段時間內成功率有波動（如在95~100%之間），可以自動降級或人工降級， 併發送告警；

（3）錯誤：比如可用率低於90%，或者資料庫連線池被打爆了，或者訪問量突然猛增到系統能承受的 最大閥值，此時可以根據情況自動降級或者人工降級；

（4）嚴重錯誤：比如因為特殊原因資料錯誤了，此時需要緊急人工降級。

服務降級的目的，是為了防止Redis服務故障，導致資料庫跟著一起發生雪崩問題。因此，對於不重要的快取資料，可以採取服務降級策略，例如一個比較常見的做法就是，Redis出現問題，不去資料庫查詢，而是直接返回預設值給使用者。