從下面的**看，快取的更新策略大概氛圍三種、本文將從一致性和維護成本兩個方面對於三種快取更新策略進行簡要說明，因為這些東西比較理論和抽象、入**說得不對，歡迎拍磚注：
1):一致性：快取和真實資料來源（例如mysql, hbase, elasticsearch等等）是否存在一段時間資料的不一致。
2):維護成本: 開發人員的開發和維護成本。
策略一致性維護成本
lru/lirs/fifo演算法剔除最差低
超時剔除
較差較低
主動更新強高
1、使用場景
通常用於快取使用量超出了預設的最大值的時候（快取空間不夠），如何對現有的資料進行清理。例如fifo吧最新進入的快取的資料清理出去，lru會把最近最少使用的清理掉
例如：memcache使用的事lru，具體memcache是如何實現的這裡就不在做贅述了，網上資料多得是。
例如：redis使用的是maxmemory-policy這個配置作為記憶體最大值後對於資料的更新策略
配置名含義預設值
maxmemory
最大可用記憶體
不使用該配置，也就對記憶體使用無限制
maxmemory-policy
記憶體不夠時,淘汰策略
volatile-lru
- volatile-lru -> 用lru演算法刪除過期的鍵值
- allkeys-lru -> 用lru演算法刪除所有鍵值
- volatile-random -> 隨機刪除過期的鍵值
- allkeys-random -> 隨機刪除任何鍵值
- volatile-ttl -> 刪除最近要到期的鍵值
- noeviction -> 不刪除鍵，只返回乙個錯誤
2、常用演算法：
這裡不再贅述，常用的演算法有如下幾種：
fifo[first in first out]
lfu[less frequently used]
lru[least recently used]
3、 一致性
可以想象，要清理的那些資料，不是有開發者決定的（只能決定大致方向，策略演算法），資料一致性是最差的
4、維護成本
這些演算法不需要開發者自己去實現，通常只需要配置最大maxmemory和對應的策略即可
開發者只需要有這個東西，知道是什麼意思，選擇自己需求的演算法，演算法的實現由快取伺服器實現
1、使用場景
就是通常我們所說的快取過期時間設定，列入redis和memcache都提供了expire這樣的api，來設定k-v的過期時間。一般來說業務可以容忍一段時間內（例如乙個小時），快取資料和真實資料（例如：mysql,hbase等等）資料不一致（一般來說，快取可以提高訪問速度，降低後端負載），那麼我們可以對乙個資料設定一定時間的過期時間，在資料過期後，再從真實資料來源獲取資料，我們可以容忍乙個小時內資料不一致，但是涉及一些錢的方面，如果不一致可想而知
2、一致性
一段時間內（取決於過期時間）存在資料一致性問題，即快取資料與真實資料來源資料不一致
3、維護成本
使用者的維護成本不是很高，只需要設定expire過期時間（前提是你的業務允許這段時間可能發生的資料不一致）
1、使用場景
業務對於一致性要求很高，需要在真實資料更新後，要立即更新快取裡資料。
具體做法：例如可以利用訊息系統或者其他方式（比如資料庫觸發器，獲取其他資料來源的listener機制來完成），通知快取更新
2、 一致性
可以想象一致性是最高（幾乎接近強一致），但是有乙個問題：如果主動更新發生了問題，那這條資料很可能長時間不會再更新了（所以可以結合超時剔除一起使用，下面最佳實踐會說到）
3、維護成本
相當高，使用者需要自己來完成更新（需要一定量的**，從某種程度上加大了系統的複雜性），需要自己檢查資料是否真的更新了之類的工作。
其實最佳的實踐就是組合使用
一般來說我們都需要配置超過最大快取後的更新策略（例如：lru）以及最大記憶體，這樣可以保證系統可以繼續執行（例如redis可能存在oom問題）（極端情況下除外，資料一致性要求極高）。
一般來說我們需要把超時剔除和主動更新組合使用，那樣即使主動更新出了問題，也能保證過期時間後，快取就被清除了（不至於永遠 都是髒資料）。
快取更新策略
一般來說，快取有以下三種模式 cache aside更新模式 這種策略下，在併發寫的時候可能會出現髒資料的問題。read write through 更新模式 在read write through 更新模式中，應用程式只需要維護快取，資料庫的維護工作由快取 了。read through 模式就是在...
快取更新策略初探
這裡為什麼不讓更新操作在寫完資料庫之後，緊接著去把快取cache中的資料也修改了呢？主要是因為這樣做的話，就有2個寫操作的事件了，擔心在併發的情況下會導致髒資料，舉個例子 那麼 cache aside 模式就沒有髒資料問題了嗎？不是的，在極端情況下也可能會產生髒資料，比如 不過這種概率比上面一種概率...
Mysql 之 快取更新策略
業務角度，對於讀操作很少的，造成效能浪費 執行緒安全角度，容易產生資料髒讀 執行緒a更新了資料庫，執行緒b更新了資料庫，b更新了快取，a更新了快取 錯誤情況 請求a進行寫操作，刪除快取 請求b查詢發現快取不存在，讀取資料庫，寫入快取 請求a將資料寫入資料庫 解決方法 採用延時雙刪除法 在a寫入資料庫...