轉載請註明出處：http://carlosfu.iteye.com/blog/2269678
一、緩存的幾種更新策略
從下面的表格看，緩存的更新策略大概氛圍三種、本文將從一致性和維護成本兩個方面對於三種緩存更新策略進行簡要說明，因爲這些東西比較理論和抽象、入哪裏說得不對，歡迎拍磚
注：
1):一致性：緩存和真實數據源（例如mysql, hbase, elasticsearch等等）是否存在一段時間數據的不一致。
2):維護成本: 開發人員的開發和維護成本。
策略 |
一致性 |
維護成本 |
|---|---|---|
| LRU/LIRS/FIFO算法剔除 | 最差 | 低 |
| 超時剔除 | 較差 | 較低 |
| 主動更新 | 強 | 高 |
二、LRU/LFU/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問題）（極端情況下除外，數據一致性要求極高）。
一般來說我們需要把超時剔除和主動更新組合使用，那樣即使主動更新出了問題，也能保證過期時間後，緩存就被清除了（不至於永遠 都是髒數據）。