使用緩存合理性

使用緩存的時機

熱點數據

對於冷數據而言，讀取頻率低，大部分數據可能尚未再次訪問到就已經被擠出內存，不只佔用內存，並且價值不大。
對於熱點數據，讀取頻率高。若是不作緩存，給數據庫形成很大的壓力，可能被擊穿。

修改頻率

數據更新前至少讀取兩次，緩存纔有意義。這個是最基本的策略，若是緩存尚未起做用就失效了，那就沒有太大價值了。（讀取頻率>修改頻率）

若是這個讀取接口對數據庫的壓力很大，可是又是熱點數據，這個時候就須要考慮經過緩存手段，減小數據庫的壓力，好比咱們的某助手產品的，點贊數，收藏數，分享數等是很是典型的熱點數據，可是又不斷變化，此時就須要將數據同步保存到Redis緩存，減小數據庫壓力

緩存更新機制

通常狀況下，咱們採起緩存雙淘汰機制，在更新數據庫的時候淘汰緩存。此外，設定超時時間，例如30分鐘。極限場景下，即便有髒數據入cache，這個髒數據也最多存在三十分鐘。

在高併發的狀況下，設計上最好避免查詢Mysql，因此在更新數據庫的時候更新緩存。

緩存可用性

緩存是提升數據讀取性能的，緩存數據丟失和緩存不可用不會影響應用程序的處理。所以，通常的操做手段是，若是Redis出現異常，咱們手動捕獲這個異常，記錄日誌，而且去數據庫查詢數據返回給用戶。

服務降級

服務降級的目的，是爲了防止Redis服務故障，致使數據庫跟着一塊兒發生雪崩問題。所以，對於不重要的緩存數據，能夠採起服務降級策略，例如一個比較常見的作法就是，Redis出現問題，不去數據庫查詢，而是直接返回默認值給用戶。

對於可用性、服務降級實際狀況

在大公司，redis都是codis集羣，通常整個codis是不會掛掉的。因此在程序代碼上沒去實現可用性、服務降級。（不知我說的對不對，你們參考就好）

緩存預熱

在新啓動的緩存系統中，若是沒有任何數據，在重建緩存數據過程當中，系統的性能和數據庫複製都不太好，那麼最好的緩存系統啓動時就把熱點數據加載好，例如對於緩存信息，在啓動緩存加載數據庫中所有數據進行預熱。通常狀況下，咱們會開通一個同步數據的接口，進行緩存預熱。