不是所有的請求都能查到數據，不論是從緩存中還是DB中。

假如黑客攻擊了一個論壇，用了一堆肉雞訪問一個不存的 帖子id 。按照常規思路，每次都會先查緩存，緩存中沒有，接著又查DB，同樣也沒有，此時不會預熱到Cache中，導致每次查詢，都會 cache miss。

由于DB的吞吐性能較差，會嚴重影響系統的性能，甚至影響正常用戶的訪問。

解決方案：

• 方案一：查存DB 時，如果數據不存在，預熱一個 特殊空值 到緩存中。這樣，后續查詢都會命中緩存，但是要對特殊值，解析處理。

• 方案二：構造一個 BloomFilter 過濾器，初始化全量數據，當接到請求時，在 BloomFilter 中判斷這個key是否存在，如果不存在，直接返回即可，無需再查詢 緩存和DB。

緩存雪崩是指部分緩存節點不可用，進而導致整個緩存體系甚至服務系統不可用的情況。

分布式緩存設計一般選擇 一致性Hash ，當有部分節點異常時，采用 rehash 策略，即把異常節點請求平均分散到其他緩存節點。但是，當較大的流量洪峰到來時，如果大流量 key 比較集中，正好在某 1～2 個緩存節點，很容易將這些緩存節點的內存、網卡過載，緩存節點異常 Crash，然后這些異常節點下線，這些大流量 key 請求又被 rehash 到其他緩存節點，進而導致其他緩存節點也被過載 Crash，緩存異常持續擴散，最終導致整個緩存體系異常，無法對外提供服務。

解決方案：

• 方案一：增加實時監控，及時預警。通過機器替換、各種故障自動轉移策略，快速恢復緩存對外的服務能力。

• 方案二：緩存增加多個副本，當緩存異常時，再讀取其他緩存副本。為了保證副本的可用性，盡量將多個緩存副本部署在不同機架上，降低風險。

當訪問緩存時，如果key對應的value過大，讀寫、加載很容易超時，容易引發網絡擁堵。另外緩存的字段較多時，每個字段的變更都會引發緩存數據的變更，頻繁的讀寫，導致慢查詢。如果大key過期被緩存淘汰失效，預熱數據要花費較多的時間，也會導致慢查詢。

所以我們在設計緩存的時候，要注意 緩存的粒度 ，既不能過大，如果過大很容易導致網絡擁堵；也不能過小，如果太小，查詢頻率會很高，每次請求都要查詢多次。

解決方案：

• 方案一：設置一個閾值，當value的長度超過閾值時，對內容啟動壓縮，降低kv的大小。

• 方案二：評估 大key 所占的比例，由于很多框架采用 池化技術 ，如：Memcache，可以預先分配大對象空間。真正業務請求時，直接拿來即用。

• 方案三：顆粒劃分，將大key拆分為多個小key，獨立維護，成本會降低不少

• 方案四：大key要設置合理的過期時間，盡量不淘汰那些大key。

緩存是用來加速的，一般不會持久化儲存。所以，一份數據通常會存在 DB 和 緩存 中，由此會帶來一個問題，如何保證這兩者的數據一致性。另外，緩存熱點問題會引入多個副本備份，也可能會發生不一致現象。

解決方案：

• 方案一：當緩存更新失敗后，進行重試，如果重試失敗，將失敗的key寫入MQ消息隊列，通過異步任務補償緩存，保證數據的一致性。

• 方案二：設置一個較短的過期時間，通過自修復的方式，在緩存過期后，緩存重新加載最新的數據。

互聯網系統典型的特點就是流量大，一旦緩存中的數據過期、或因某些原因被刪除等，導致緩存中的數據為空，大量的并發線程請求（查詢同一個key）就會一起并發查詢數據庫， 數據庫 的壓力陡然增加。

如果請求量非常大，全部壓在數據庫，可能把數據庫壓垮，進而導致整個系統的服務不可用。

解決方案：

• 方案一：引入一把 全局鎖 ，當緩存未命中時，先嘗試獲取全局鎖，如果拿到鎖，才有資格去查詢DB，并將數據預熱到緩存中。雖然，client端發起的請求非常多，但是由于拿不到鎖，只能處于等待狀態，當緩存中的數據預熱成功后，再從緩存中獲取。

為了便于理解，簡單畫了個流程圖。這里面特別注意一個點，由于有一個并發時間差，所以會有一個二次check緩存是否有值的校驗，防止緩存預熱重復覆蓋。

• 方案二：緩存數據創建多個備份，當一個過期失效后，可以訪問其他備份。