轉載請註明出處哈: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. 維護成本：
相當高，用戶需要自己來完成更新（需要一定量的代碼，從某種程度上加大了系統的複雜性），需要自己檢查數據是否真的更新了之類的工作。
五、最佳實踐
其實最佳實踐就是組合使用：
1. 一般來說我們都需要配置超過最大緩存後的更新策略（例如：LRU）以及最大內存，這樣可以保證系統可以繼續運行（例如redis可能存在OOM問題）（極端情況下除外，數據一致性要求極高）。
2. 一般來說我們需要把超時剔除和主動更新組合使用，那樣即使主動更新出了問題，也能保證過期時間後，緩存就被清除了（不至於永遠都是髒數據）。