方案分析
更新緩存策略方式常見的有下面幾種：
- 先更新緩存，再更新數據庫
- 先更新數據庫，再更新緩存
- 先刪除緩存，再更新數據庫
- 先更新數據庫，再刪除緩存
下面一一介紹！
方案一：更新緩存，更新數據庫這種方式可輕易排除，因為如果先更新緩存成功，但是數據庫更新失敗，則肯定會造成數據不一致。
方案二：更新數據庫，更新緩存這種緩存更新策略俗稱雙寫，存在問題是：並發更新數據庫場景下，會將臟數據刷到緩存
舉例：如果在兩個操作之間數據庫和緩存又被后面請求修改，此時再去更新緩存已經是過期數據了。
方案三：刪除緩存，更新數據庫存在問題：更新數據庫之前，若有查詢請求，會將臟數據刷到緩存
舉例：如果在兩個操作之間發生了數據查詢，那么會有舊數據放入緩存。
該方案會導致請求數據不一致如果同時有一個請求A進行更新操作，另一個請求B進行查詢操作。那么會出現如下情形:
- 請求A進行寫操作，刪除緩存
- 請求B查詢發現緩存不存在
- 請求B去數據庫查詢得到舊值
- 請求B將舊值寫入緩存
- 請求A將新值寫入數據庫
上述情況就會導致不一致的情形出現。而且，如果不采用給緩存設置過期時間策略，該數據永遠都是臟數據。
方案四：更新數據庫，刪除緩存存在問題：在更新數據庫之前有查詢請求，並且緩存失效了，會查詢數據庫，然后更新緩存。如果在查詢數據庫和更新緩存之間進行了數據庫更新的操作，那么就會把臟數據刷到緩存
舉例：如果在查詢數據庫和放入緩存這兩個操作中間發生了數據更新並且刪除緩存，那么會有舊數據放入緩存。
假設有兩個請求，一個請求A做查詢操作，一個請求B做更新操作，那么會有如下情形產生
- 緩存剛好失效
- 請求A查詢數據庫，得一個舊值
- 請求B將新值寫入數據庫
- 請求B刪除緩存
- 請求A將查到的舊值寫入緩存
如果發生上述情況，確實是會發生臟數據。但是發生上述情況有一個先天性條件，就是寫數據庫操作比讀數據庫操作耗時更短不過數據庫的讀操作的速度遠快於寫操作的因此這一情形很難出現。
方案對比
方案1和方案2的共同缺點：並發更新數據庫場景下，會將臟數據刷到緩存，但一般並發寫的場景概率都相對小一些；線程安全角度，會產生臟數據，比如：
- 線程A更新了數據庫
- 線程B更新了數據庫
- 線程B更新了緩存
- 線程A更新了緩存
方案3和方案4的共同缺點：不管采用哪種順序，2種方式都是存在一些問題的：
- 主從延時問題：不管是先刪除還是后刪除，數據庫主從延時可能導致臟數據的產生。
- 緩存刪除失敗：如果緩存刪除失敗，則都會產生臟數據。
問題解決思路：延遲雙刪，添加重試機制，下面介紹！更新緩存還是刪除緩存？
1.更新緩存緩存需要有一定的維護成本，而且會存在並發更新的問題
2.寫多讀少的情況下，讀請求還沒有來，緩存以及被更新很多次，沒有起到緩存的作用
3.放入緩存的值可能是經過復雜計算的，如果每次更新，都計算寫入緩存的值，浪費性能的刪除緩存優點：簡單、成本低，容易開發；缺點：會造成一次cache miss如果更新緩存開銷較小並且讀多寫少，基本不會有寫並發的時候可以才用更新緩存，否則通用做法還是刪除緩存。
總結
方案問題問題出現概率推薦程度
| 更新緩存 -> 更新數據庫 | 為了保證數據准確性，數據必須以數據庫更新結果為准，所以該方案絕不可行 | 大 | 不推薦 |
| 更新數據庫 -> 更新緩存 | 並發更新數據庫場景下，會將臟數據刷到緩存 | 並發寫場景，概率一般 | 寫請求較多時會出現不一致問題，不推薦使用。 |
| 刪除緩存 -> 更新數據庫 | 更新數據庫之前，若有查詢請求，會將臟數據刷到緩存 | 並發讀場景，概率較大 | 讀請求較多時會出現不一致問題，不推薦使用 |
| 更新數據庫 -> 刪除緩存 | 在更新數據庫之前有查詢請求，並且緩存失效了，會查詢數據庫，然后更新緩存。如果在查詢數據庫和更新緩存之間進行了數據庫更新的操作，那么就會把臟數據刷到緩存 | 並發讀場景&讀操作慢於寫操作，概率最小 | 讀操作比寫操作更慢的情況較少，相比於其他方式出錯的概率小一些。勉強推薦。 |
推薦方案
延遲雙刪
采用更新前后雙刪除緩存策略
public void write(String key,Object data){
redis.del(key);
db.update(data);
Thread.sleep(1000);
redis.del(key);
}
- 先淘汰緩存
- 再寫數據庫
- 休眠1秒，再次淘汰緩存
大家應該評估自己的項目的讀數據業務邏輯的耗時。然后寫數據的休眠時間則在讀數據業務邏輯的耗時基礎上即可。
這么做的目的，就是確保讀請求結束，寫請求可以刪除讀請求造成的緩存臟數據。
問題及解法：
1、同步刪除，吞吐量降低如何處理
將第二次刪除作為異步的，提交一個延遲的執行任務
2、解決刪除失敗的方式：
添加重試機制，例如：將刪除失敗的key，寫入消息隊列；但對業務耦合有些嚴重；
延時工具可以選擇：最普通的阻塞Thread.currentThread().sleep(1000);
Jdk調度線程池，quartz定時任務，利用jdk自帶的delayQueue，netty的HashWheelTimer，Rabbitmq的延時隊列，等等
實際場景
我們有個商品中心的場景，是讀多寫少的服務，並且寫數據會發送MQ通知下游拿數據，這樣就需要嚴格保證緩存和數據庫的一致性，需要提供高可靠的系統服務能力。
寫緩存策略
- 緩存key設置失效時間
- 先DB操作，再緩存失效
- 寫操作都標記key（美團中間件）強制走主庫
- 接入美團中間件監聽binlog（美團中間件）變化的數據在進行兜底，再刪除緩存
讀緩存策略
- 先判斷是否走主庫
- 如果走主庫，則使用標記（美團中間件）查主庫
- 如果不是，則查看緩存中是否有數據
- 緩存中有數據，則使用緩存數據作為結果
- 如果沒有，則查DB數據，再寫數據到緩存
注意
關於緩存過期時間的問題
如果緩存設置了過期時間，那么上述的所有不一致情況都只是暫時的。
但是如果沒有設置過期時間，那么不一致問題就只能等到下次更新數據時解決。
所以一定要設置緩存過期時間。