如何使用快取，怎麼才能更加合理？今天的話題，結合我之前的專案場景，討論下使用快取合理性問題。
對於冷資料而言，大部分資料可能還沒有再次訪問到就已經被擠出記憶體，不僅占用記憶體，而且價值不大。
對於熱點資料，比如我們的某im產品，生日祝福模組，當天的壽星列表，快取以後可能讀取數十萬次。再舉個例子，某導航產品，我們將導航資訊，快取以後可能讀取數百萬次。
資料更新前至少讀取兩次，快取才有意義。這個是最基本的策略，如果快取還沒有起作用就失效了，那就沒有太大價值了。
對於上面兩個例子，壽星列表、導航資訊都存在乙個特點，就是資訊修改頻率不高，讀取通常非常高的場景。
那存不存在，修改頻率很高，但是又不得不考慮快取的場景呢？有！比如，這個讀取介面對資料庫的壓力很大，但是又是熱點資料，這個時候就需要考慮通過快取手段，減少資料庫的壓力，比如我們的某助手產品的，點讚數，收藏數，分享數等是非常典型的熱點資料，但是又不斷變化，此時就需要將資料同步儲存到redis快取，減少資料庫壓力。
使用快取過程中，我們經常會遇到快取資料的不一致性和與髒讀現象，我們有什麼解決策略呢？
一般情況下，我們採取快取雙淘汰機制，在更新資料庫的時候淘汰快取。此外，設定超時時間，例如30分鐘。極限場景下，即使有髒資料入cache，這個髒資料也最多存在三十分鐘。
快取是提高資料讀取效能的，快取資料丟失和快取不可用不會影響應用程式的處理。因此，一般的操作手段是，如果redis出現異常，我們手動捕獲這個異常，記錄日誌，並且去資料庫查詢資料返回給使用者。
服務降級的目的，是為了防止redis服務故障，導致資料庫跟著一起發生雪崩問題。因此，對於不重要的快取資料，可以採取服務降級策略，例如乙個比較常見的做法就是，redis出現問題，不去資料庫查詢，而是直接返回預設值給使用者。
在新啟動的快取系統中，如果沒有任何資料，在重建快取資料過程中，系統的效能和資料庫複製都不太好，那麼最好的快取系統啟動時就把熱點資料載入好，例如對於快取資訊，在啟動快取載入資料庫中全部資料進行預熱。一般情況下，我們會開通乙個同步資料的介面，進行快取預熱。
如果因為不恰當的業務，或者惡意攻擊持續地發請求某些不存在的資料，由於快取沒有儲存該資料，所有的請求都會落到資料庫上，會對資料庫造成很大壓力，甚至奔潰。乙個簡單的對策是將不存在的資料也快取起來。
原文：
Redis實戰（一） 使用快取合理性
如何使用快取，怎麼才能更加合理？今天的話題，結合我之前的專案場景，討論下使用快取合理性問題。對於冷資料而言，大部分資料可能還沒有再次訪問到就已經被擠出記憶體，不僅占用記憶體，而且價值不大。對於熱點資料，比如我們的某im產品，生日祝福模組，當天的壽星列表，快取以後可能讀取數十萬次。再舉個例子，某導航產...
任務排程的合理性
假定乙個工程專案由一組子任務構成，子任務之間有的可以並行執行，有的必須在完成了其它一些子任務後才能執行。任務排程 包括一組子任務 以及每個子任務可以執行所依賴的子任務集。比如完成乙個專業的所有課程學習和畢業設計可以看成乙個本科生要完成的一項工程，各門課程可以看成是子任務。有些課程可以同時開設，比如英...
棧元素的合理性
輸入一串行的元素，判斷另一列元素是否符合棧的 先進後出 性質 include include include using namespace std bool check int stack in,int stack out,int len in,int len out return s.size ...