如何使用快取，怎麼才能更加合理？今天的話題，結合我之前的專案場景，討論下使用快取合理性問題。

熱點資料，快取才有價值

對於冷資料而言，大部分資料可能還沒有再次訪問到就已經被擠出記憶體，不僅佔用記憶體，而且價值不大。

對於熱點資料，比如我們的某IM產品，生日祝福模組，當天的壽星列表，快取以後可能讀取數十萬次。再舉個例子，某導航產品，我們將導航資訊，快取以後可能讀取數百萬次。

頻繁修改的資料，看情況考慮使用快取

資料更新前至少讀取兩次，快取才有意義。這個是最基本的策略，如果快取還沒有起作用就失效了，那就沒有太大價值了。

對於上面兩個例子，壽星列表、導航資訊都存在一個特點，就是資訊修改頻率不高，讀取通常非常高的場景。

那存不存在，修改頻率很高，但是又不得不考慮快取的場景呢？有！比如，這個讀取介面對資料庫的壓力很大，但是又是熱點資料，這個時候就需要考慮通過快取手段，減少資料庫的壓力，比如我們的某助手產品的，點贊數，收藏數，分享數等是非常典型的熱點資料，但是又不斷變化，此時就需要將資料同步儲存到Redis快取，減少資料庫壓力。

資料不一致性

一般會對快取設定失效時間，一旦超過失效時間，就要從資料庫重新載入，因此應用要容忍一定時間的資料不一致。還有一種是在資料更新時立即更新快取，不過這也會更多系統開銷和事務一致性問題。

快取更新機制

使用快取過程中，我們經常會遇到快取資料的不一致性和與髒讀現象，我們有什麼解決策略呢？

一般情況下，我們採取快取雙淘汰機制，在更新資料庫的時候淘汰快取。此外，設定超時時間，例如30分鐘。極限場景下，即使有髒資料入cache，這個髒資料也最多存在三十分鐘。

快取可用性

快取是提高資料讀取效能的，快取資料丟失和快取不可用不會影響應用程式的處理。因此，一般的操作手段是，如果Redis出現異常，我們手動捕獲這個異常，記錄日誌，並且去資料庫查詢資料返回給使用者。

快取服務降級

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

快取預熱

在新啟動的快取系統中，如果沒有任何資料，在重建快取資料過程中，系統的效能和資料庫複製都不太好，那麼最好的快取系統啟動時就把熱點資料載入好，例如對於快取資訊，在啟動快取載入資料庫中全部資料進行預熱。一般情況下，我們會開通一個同步資料的介面，進行快取預熱。

快取穿透

如果因為不恰當的業務，或者惡意攻擊持續地發請求某些不存在的資料，由於快取沒有儲存該資料，所有的請求都會落到資料庫上，會對資料庫造成很大壓力，甚至奔潰。一個簡單的對策是將不存在的資料也快取起來。