我們再看一下剛才的計算機分層結構。LLC 的大小是 MB 級別，page cache 的大小是 GB 級別，而磁碟的大小是 TB 級別。這其實包含了快取的第二個特徵：快取系統的容量大小總是小於後端慢速系統的，我們不可能把所有資料都放在快取系統中

  舉個例子，在商品大促的場景中，商品的庫存資訊會一直被修改。如果每次修改都需到資料庫中處理，就會拖慢整個應用，此時，我們通常會選擇讀寫快取的模式。而在短視訊 App 的場景中，雖然視訊的屬性有很多，但是，一般確定後，修改並不頻繁，此時，在資料庫中進行修改對快取影響不大，所以只讀快取模式是一個合適的選擇

24 | 替換策略：快取滿了怎麼辦？

設定多大的快取容量合適？快取容量設定得是否合理，會直接影響到使用快取的價效比。我們通常希望以最小的代價去獲得最大的收益，所以，把昂貴的記憶體資源用在關鍵地方就非常重要了

   正是因為 20% 的資料不一定能貢獻 80% 的訪問量，我們不能簡單地按照“總資料量的 20%”來設定快取最大空間容量。在實踐過程中，我看到過的快取容量佔總資料量的比例，從 5% 到 40% 的都有。這個容量規劃不能一概而論，是需要結合應用資料實際訪問特徵和成本開銷來綜合考慮的。

 

這其實也是我一直在和你分享的經驗，系統的設計選擇是一個權衡的過程：大容量快取是能帶來效能加速的收益，但是成本也會更高，而小容量快取不一定就起不到加速訪問的效果。一般來說，我會建議把快取容量設定為總資料量的 15% 到 30%，兼顧訪問效能和記憶體空間開銷

 

25 | 快取異常（上）：如何解決快取和資料庫的資料不一致問題？

好了，到這裡，我們瞭解到了，快取和資料庫的資料不一致一般是由兩個原因導致的，我給你提供了相應的解決方案。刪除快取值或更新資料庫失敗而導致資料不一致，你可以使用重試機制確保刪除或更新操作成功。在刪除快取值、更新資料庫的這兩步操作中，有其他執行緒的併發讀操作，導致其他執行緒讀取到舊值，應對方案是延遲雙刪。

26 | 快取異常（下）：如何解決快取雪崩、擊穿、穿透難題？

除了大量資料同時失效會導致快取雪崩，還有一種情況也會發生快取雪崩，那就是，Redis 快取例項發生故障當機了，無法處理請求，這就會導致大量請求一下子積壓到資料庫層，從而發生快取雪崩。

 

    為了避免快取擊穿給資料庫帶來的激增壓力，我們的解決方法也比較直接，對於訪問特別頻繁的熱點資料，我們就不設定過期時間了。這樣一來，對熱點資料的訪問請求，都可以在快取中進行處理，而 Redis 數萬級別的高吞吐量可以很好地應對大量的併發請求訪問