一、緩存的幾種更新策略
從下面的表格看，緩存的更新策略大致分為三種，本文將從一致性和維護(hù)成本兩個方面對于三種緩存更新策略進(jìn)行簡要說明，因為這些東西比較理論和抽象，如哪里說得不對，歡迎拍磚。
注：
(1) 一致性：緩存和真實數(shù)據(jù)源（例如mysql, hbase, elasticsearch等等）是否存在一段時間數(shù)據(jù)的不一致。
(2) 維護(hù)成本: 開發(fā)人員的開發(fā)和維護(hù)成本。
| 策略 | 一致性 | 維護(hù)成本 |
| LRU/LIRS/FIFO算法剔除 | 最差 | 低 |
| 超時剔除 | 較差 | 較低 |
| 主動更新 | 強(qiáng) | 高 |
二、LRU/LFU/FIFO算法剔除
1. 使用場景：
通常用于緩存使用量超過了預(yù)設(shè)的最大值時候（緩存空間不夠），如何對現(xiàn)有的數(shù)據(jù)進(jìn)行清理。例如FIFO會把最新進(jìn)入緩存的數(shù)據(jù)清理出去, LRU會把最近最少使用的數(shù)據(jù)清理掉。
例如：Memcache使用的是LRU，具體Memcache如何實現(xiàn)的，這里就不在贅述了，網(wǎng)上資料多的是。
例如：Redis使用maxmemory-policy這個配置作為內(nèi)存最大值后對于數(shù)據(jù)的更新策略。
| 配置名 | 含義 | 默認(rèn)值 |
| maxmemory | 最大可用內(nèi)存 | 不使用該配置，也就對內(nèi)存使用無限制 |
| maxmemory-policy | 內(nèi)存不夠時,淘汰策略 | volatile-lru |
- volatile-lru -> 用lru算法刪除過期的鍵值
- allkeys-lru -> 用lru算法刪除所有鍵值
- volatile-random -> 隨機(jī)刪除過期的鍵值
- allkeys-random -> 隨機(jī)刪除任何鍵值
- volatile-ttl -> 刪除最近要到期的鍵值
- noeviction -> 不刪除鍵，只返回一個錯誤
2. 常用算法：
這里不再贅述，常用的算法有如下幾種：
FIFO[first in first out]
LFU[Less Frequently Used]
LRU[Least Recently used]
3. 一致性
可以想象，要清理哪些數(shù)據(jù)，不是由開發(fā)者決定（只能決定大致方向：策略算法），數(shù)據(jù)的一致性是最差的。
4. 維護(hù)成本
這些算法不需要開發(fā)者自己來實現(xiàn)，通常只需要配置最大maxmemory和對應(yīng)的策略即可。
開發(fā)者只需要有這個東西，知道是什么意思，選擇自己需要的算法，算法的實現(xiàn)是由緩存服務(wù)器實現(xiàn)的。
三、超時剔除
1. 使用場景：
就是我們通常做的緩存數(shù)據(jù)過期時間設(shè)置，例如redis和memcache都提供了expire這樣的API，來設(shè)置K-V的過期時間。
一般來說業(yè)務(wù)可以容忍一段時間內(nèi)（例如一個小時），緩存數(shù)據(jù)和真實數(shù)據(jù)（例如：mysql, hbase等等）數(shù)據(jù)不一致（一般來說，緩存可以提高訪問速度降低后端負(fù)載），那么我們可以對一個數(shù)據(jù)設(shè)置一定時間的過期時間，在數(shù)據(jù)過期后，再從真實數(shù)據(jù)源獲取數(shù)據(jù)，重新放到緩存中，繼續(xù)設(shè)置過期時間。
例如： 一個視頻的描述信息，我們可以容忍一個小時內(nèi)數(shù)據(jù)不一致，但是涉及到錢的方面，如果不一致可想而知。
2. 一致性：
一段時間內(nèi)（取決于過期時間）存在數(shù)據(jù)一致性問題，即緩存數(shù)據(jù)和真實數(shù)據(jù)源數(shù)據(jù)不一致。
3. 維護(hù)成本
用戶的維護(hù)成本不是很高，只需要設(shè)置expire過期時間即可（前提是你的業(yè)務(wù)允許這段時間可能發(fā)生的數(shù)據(jù)不一致）。
四、主動更新
1. 使用背景：
業(yè)務(wù)對于數(shù)據(jù)的一致性要求很高，需要在真實數(shù)據(jù)更新后，立即更新緩存數(shù)據(jù)。
具體做法：例如可以利用消息系統(tǒng)或者其他方式（比如數(shù)據(jù)庫觸發(fā)器，或者其他數(shù)據(jù)源的listener機(jī)制來完成）通知緩存更新。
2. 一致性：
可以想象一致性最高（幾乎接近強(qiáng)一致），但是有個問題：如果主動更新發(fā)生了問題，那么這條數(shù)據(jù)很可能很長時間不會更新了（所以可以結(jié)合超時剔除一起使用，下面最佳實踐會說到）
3. 維護(hù)成本：
相當(dāng)高，用戶需要自己來完成更新（需要一定量的代碼，從某種程度上加大了系統(tǒng)的復(fù)雜性），需要自己檢查數(shù)據(jù)是否真的更新了之類的工作。
五、最佳實踐
其實最佳實踐就是組合使用：
1. 一般來說我們都需要配置超過最大緩存后的更新策略（例如：LRU）以及最大內(nèi)存，這樣可以保證系統(tǒng)可以繼續(xù)運行（例如redis可能存在OOM問題）（極端情況下除外，數(shù)據(jù)一致性要求極高）。
2. 一般來說我們需要把超時剔除和主動更新組合使用，那樣即使主動更新出了問題，也能保證過期時間后，緩存就被清除了（不至于永遠(yuǎn)都是臟數(shù)據(jù)）。