http://blog.720ui.com/2016/redis_action_01_use_core/
如何使用緩存，怎么才能更加合理？今天的話題，結合我之前的項目場景，討論下使用緩存合理性問題。
熱點數據，緩存才有價值
對于冷數據而言，大部分數據可能還沒有再次訪問到就已經被擠出內存，不僅占用內存，而且價值不大。
對于熱點數據，比如我們的某IM產品，生日祝福模塊，當天的壽星列表，緩存以后可能讀取數十萬次。再舉個例子，某導航產品，我們將導航信息，緩存以后可能讀取數百萬次。
頻繁修改的數據，看情況考慮使用緩存
數據更新前至少讀取兩次，緩存才有意義。這個是最基本的策略，如果緩存還沒有起作用就失效了，那就沒有太大價值了。
對于上面兩個例子，壽星列表、導航信息都存在一個特點，就是信息修改頻率不高，讀取通常非常高的場景。
那存不存在，修改頻率很高，但是又不得不考慮緩存的場景呢？有！比如，這個讀取接口對數據庫的壓力很大，但是又是熱點數據，這個時候就需要考慮通過緩存手段，減少數據庫的壓力，比如我們的某助手產品的，點贊數，收藏數，分享數等是非常典型的熱點數據，但是又不斷變化，此時就需要將數據同步保存到Redis緩存，減少數據庫壓力。
數據不一致性
一般會對緩存設置失效時間，一旦超過失效時間，就要從數據庫重新加載，因此應用要容忍一定時間的數據不一致。還有一種是在數據更新時立即更新緩存，不過這也會更多系統開銷和事務一致性問題。
緩存更新機制
使用緩存過程中，我們經常會遇到緩存數據的不一致性和與臟讀現象，我們有什么解決策略呢？
一般情況下，我們采取緩存雙淘汰機制，在更新數據庫的時候淘汰緩存。此外，設定超時時間，例如30分鐘。極限場景下，即使有臟數據入cache，這個臟數據也最多存在三十分鐘。
緩存可用性
緩存是提高數據讀取性能的，緩存數據丟失和緩存不可用不會影響應用程序的處理。因此，一般的操作手段是，如果Redis出現異常，我們手動捕獲這個異常，記錄日志，并且去數據庫查詢數據返回給用戶。
緩存服務降級
服務降級的目的，是為了防止Redis服務故障，導致數據庫跟著一起發生雪崩問題。因此，對于不重要的緩存數據，可以采取服務降級策略，例如一個比較常見的做法就是，Redis出現問題，不去數據庫查詢，而是直接返回默認值給用戶。
緩存預熱
在新啟動的緩存系統中，如果沒有任何數據，在重建緩存數據過程中，系統的性能和數據庫復制都不太好，那么最好的緩存系統啟動時就把熱點數據加載好，例如對于緩存信息，在啟動緩存加載數據庫中全部數據進行預熱。一般情況下，我們會開通一個同步數據的接口，進行緩存預熱。
緩存穿透
如果因為不恰當的業務，或者惡意攻擊持續地發請求某些不存在的數據，由于緩存沒有保存該數據，所有的請求都會落到數據庫上，會對數據庫造成很大壓力，甚至奔潰。一個簡單的對策是將不存在的數據也緩存起來。