源 / 月伴飛魚 文/ 日常加油站
前言
下面介紹幾種方案（大家回答的時(shí)候最好根據(jù)自己的業(yè)務(wù)，結(jié)合下面的方案）方案分析
這種方式可輕易排除，因?yàn)槿绻雀戮彺娉晒?，但是?shù)據(jù)庫更新失敗，則肯定會造成數(shù)據(jù)不一致。這種緩存更新策略俗稱雙寫，存在問題是：并發(fā)更新數(shù)據(jù)庫場景下，會將臟數(shù)據(jù)刷到緩存updateDB();
updateRedis();
舉例：如果在兩個(gè)操作之間數(shù)據(jù)庫和緩存又被后面請求修改，此時(shí)再去更新緩存已經(jīng)是過期數(shù)據(jù)了。存在問題：更新數(shù)據(jù)庫之前，若有查詢請求，會將臟數(shù)據(jù)刷到緩存deleteRedis();
updateDB();
舉例：如果在兩個(gè)操作之間發(fā)生了數(shù)據(jù)查詢，那么會有舊數(shù)據(jù)放入緩存。該方案會導(dǎo)致請求數(shù)據(jù)不一致如果同時(shí)有一個(gè)請求A進(jìn)行更新操作，另一個(gè)請求B進(jìn)行查詢操作。那么會出現(xiàn)如下情形:上述情況就會導(dǎo)致不一致的情形出現(xiàn)。而且，如果不采用給緩存設(shè)置過期時(shí)間策略，該數(shù)據(jù)永遠(yuǎn)都是臟數(shù)據(jù)。存在問題：在更新數(shù)據(jù)庫之前有查詢請求，并且緩存失效了，會查詢數(shù)據(jù)庫，然后更新緩存。如果在查詢數(shù)據(jù)庫和更新緩存之間進(jìn)行了數(shù)據(jù)庫更新的操作，那么就會把臟數(shù)據(jù)刷到緩存updateDB();
deleteRedis();
舉例：如果在查詢數(shù)據(jù)庫和放入緩存這兩個(gè)操作中間發(fā)生了數(shù)據(jù)更新并且刪除緩存，那么會有舊數(shù)據(jù)放入緩存。假設(shè)有兩個(gè)請求，一個(gè)請求A做查詢操作，一個(gè)請求B做更新操作，那么會有如下情形產(chǎn)生- 請求A查詢數(shù)據(jù)庫，得一個(gè)舊值
如果發(fā)生上述情況，確實(shí)是會發(fā)生臟數(shù)據(jù)。但是發(fā)生上述情況有一個(gè)先天性條件，就是寫數(shù)據(jù)庫操作比讀數(shù)據(jù)庫操作耗時(shí)更短不過數(shù)據(jù)庫的讀操作的速度遠(yuǎn)快于寫操作的方案對比
并發(fā)更新數(shù)據(jù)庫場景下，會將臟數(shù)據(jù)刷到緩存，但一般并發(fā)寫的場景概率都相對小一些；線程安全角度，會產(chǎn)生臟數(shù)據(jù)，比如：- 主從延時(shí)問題：不管是先刪除還是后刪除，數(shù)據(jù)庫主從延時(shí)可能導(dǎo)致臟數(shù)據(jù)的產(chǎn)生。
- 緩存刪除失敗：如果緩存刪除失敗，則都會產(chǎn)生臟數(shù)據(jù)。
問題解決思路：延遲雙刪，添加重試機(jī)制，下面介紹！1.更新緩存緩存需要有一定的維護(hù)成本，而且會存在并發(fā)更新的問題2.寫多讀少的情況下，讀請求還沒有來，緩存以及被更新很多次，沒有起到緩存的作用3.放入緩存的值可能是經(jīng)過復(fù)雜計(jì)算的，如果每次更新，都計(jì)算寫入緩存的值，浪費(fèi)性能的刪除緩存優(yōu)點(diǎn)：簡單、成本低，容易開發(fā)；缺點(diǎn)：會造成一次cache miss如果更新緩存開銷較小并且讀多寫少，基本不會有寫并發(fā)的時(shí)候可以才用更新緩存，否則通用做法還是刪除緩存。總結(jié)
|
|
|
|
| 為了保證數(shù)據(jù)準(zhǔn)確性，數(shù)據(jù)必須以數(shù)據(jù)庫更新結(jié)果為準(zhǔn)，所以該方案絕不可行 | | |
| 并發(fā)更新數(shù)據(jù)庫場景下，會將臟數(shù)據(jù)刷到緩存 | | 寫請求較多時(shí)會出現(xiàn)不一致問題，不推薦使用。 |
| 更新數(shù)據(jù)庫之前，若有查詢請求，會將臟數(shù)據(jù)刷到緩存 | | 讀請求較多時(shí)會出現(xiàn)不一致問題，不推薦使用 |
| 在更新數(shù)據(jù)庫之前有查詢請求，并且緩存失效了，會查詢數(shù)據(jù)庫，然后更新緩存。如果在查詢數(shù)據(jù)庫和更新緩存之間進(jìn)行了數(shù)據(jù)庫更新的操作，那么就會把臟數(shù)據(jù)刷到緩存 | | 讀操作比寫操作更慢的情況較少，相比于其他方式出錯(cuò)的概率小一些。勉強(qiáng)推薦。 |
推薦方案
延遲雙刪
public void write(String key,Object data){
redis.del(key);
db.update(data);
Thread.sleep(1000);
redis.del(key);
}
大家應(yīng)該評估自己的項(xiàng)目的讀數(shù)據(jù)業(yè)務(wù)邏輯的耗時(shí)。然后寫數(shù)據(jù)的休眠時(shí)間則在讀數(shù)據(jù)業(yè)務(wù)邏輯的耗時(shí)基礎(chǔ)上即可。這么做的目的，就是確保讀請求結(jié)束，寫請求可以刪除讀請求造成的緩存臟數(shù)據(jù)。將第二次刪除作為異步的，提交一個(gè)延遲的執(zhí)行任務(wù)添加重試機(jī)制，例如：將刪除失敗的key，寫入消息隊(duì)列；但對業(yè)務(wù)耦合有些嚴(yán)重；最普通的阻塞Thread.currentThread().sleep(1000);Jdk調(diào)度線程池，quartz定時(shí)任務(wù)，利用jdk自帶的delayQueue，netty的HashWheelTimer，Rabbitmq的延時(shí)隊(duì)列，等等實(shí)際場景
我們有個(gè)商品中心的場景，是讀多寫少的服務(wù)，并且寫數(shù)據(jù)會發(fā)送MQ通知下游拿數(shù)據(jù)，這樣就需要嚴(yán)格保證緩存和數(shù)據(jù)庫的一致性，需要提供高可靠的系統(tǒng)服務(wù)能力。寫緩存策略
- 寫操作都標(biāo)記key（美團(tuán)中間件）強(qiáng)制走主庫
- 接入美團(tuán)中間件監(jiān)聽binlog（美團(tuán)中間件）變化的數(shù)據(jù)在進(jìn)行兜底，再刪除緩存
讀緩存策略
- 如果走主庫，則使用標(biāo)記（美團(tuán)中間件）查主庫
- 如果不是，則查看緩存中是否有數(shù)據(jù)
- 緩存中有數(shù)據(jù)，則使用緩存數(shù)據(jù)作為結(jié)果
- 如果沒有，則查DB數(shù)據(jù)，再寫數(shù)據(jù)到緩存
注意
如果緩存設(shè)置了過期時(shí)間，那么上述的所有不一致情況都只是暫時(shí)的。但是如果沒有設(shè)置過期時(shí)間，那么不一致問題就只能等到下次更新數(shù)據(jù)時(shí)解決。最后
覺得有收獲，希望幫忙點(diǎn)贊，轉(zhuǎn)發(fā)下哈，謝謝，謝謝
一鍵三連「分享」、「點(diǎn)贊」和「在看」
技術(shù)干貨與你天天見~
