如何使用快取，怎麼才能更加合理？今天的話題，結合我之前的專案場景，討論下使用快取合理性問題。
對於冷資料而言，大部分資料可能還沒有再次訪問到就已經被擠出記憶體，不僅占用記憶體，而且價值不大。
對於熱點資料，比如我們的某im產品，生日祝福模組，當天的壽星列表，快取以後可能讀取數十萬次。再舉個例子，某導航產品，我們將導航資訊，快取以後可能讀取數百萬次。
資料更新前至少讀取兩次，快取才有意義。這個是最基本的策略，如果快取還沒有起作用就失效了，那就沒有太大價值了。
對於上面兩個例子，壽星列表、導航資訊都存在乙個特點，就是資訊修改頻率不高，讀取通常非常高的場景。
那存不存在，修改頻率很高，但是又不得不考慮快取的場景呢？有！比如，這個讀取介面對資料庫的壓力很大，但是又是熱點資料，這個時候就需要考慮通過快取手段，減少資料庫的壓力，比如我們的某助手產品的，點讚數，收藏數，分享數等是非常典型的熱點資料，但是又不斷變化，此時就需要將資料同步儲存到redis快取，減少資料庫壓力。
使用快取過程中，我們經常會遇到快取資料的不一致性和與髒讀現象，我們有什麼解決策略呢？
一般情況下，我們採取快取雙淘汰機制，在更新資料庫的時候淘汰快取。此外，設定超時時間，例如30分鐘。極限場景下，即使有髒資料入cache，這個髒資料也最多存在三十分鐘。
快取是提高資料讀取效能的，快取資料丟失和快取不可用不會影響應用程式的處理。因此，一般的操作手段是，如果redis出現異常，我們手動捕獲這個異常，記錄日誌，並且去資料庫查詢資料返回給使用者。
服務降級的目的，是為了防止redis服務故障，導致資料庫跟著一起發生雪崩問題。因此，對於不重要的快取資料，可以採取服務降級策略，例如乙個比較常見的做法就是，redis出現問題，不去資料庫查詢，而是直接返回預設值給使用者。
在新啟動的快取系統中，如果沒有任何資料，在重建快取資料過程中，系統的效能和資料庫複製都不太好，那麼最好的快取系統啟動時就把熱點資料載入好，例如對於快取資訊，在啟動快取載入資料庫中全部資料進行預熱。一般情況下，我們會開通乙個同步資料的介面，進行快取預熱。
如果因為不恰當的業務，或者惡意攻擊持續地發請求某些不存在的資料，由於快取沒有儲存該資料，所有的請求都會落到資料庫上，會對資料庫造成很大壓力，甚至奔潰。乙個簡單的對策是將不存在的資料也快取起來。
合理使用快取
乙個優秀的專案，其中必然使用到了快取機制 乙個 遇到效能瓶頸是，第乙個解決方案一般是使用快取，快取的應用面特別廣，無論是客戶端，還是應用伺服器，或是儲存伺服器。快取一般存放讀寫比價頻繁，變化較少的資料，應用程式讀取資料時先從快取中讀取資料，獲取不到再訪問資料庫，再放到快取中，以便於下次快速獲取。快取...
Redis快取實戰教程
目錄 redis快取 使用快取redis解決首頁併發問題 1 快取使用的簡單設計 2 redis的整合步驟 a 將redis整合到專案中 redis spring b 設計乙個資料儲存策越 3 redis的整合過程 1 引入pom依賴資訊 將本工程所有的redis統一放入service util裡 ...
redis快取使用
compile group org.springframework.boot name spring boot starter data redis version 2.3.2.release spring 主要引數 redis host localhost port 6379 passport 預...