前言
在分布式系統(tǒng)中,緩存和數(shù)據(jù)庫同時存在時,如果有寫操作,先操作數(shù)據(jù)庫還是先操作緩存呢?本文將分5種方案展開闡述對比,謝謝閱讀~github地址,衷心感謝每一顆star
?https://github.com/whx123/JavaHome?
緩存維護方案一
如果是一讀(線程B)一寫(線程A)操作,「先操作緩存,再操作數(shù)據(jù)庫」。流程圖如下所示:
1.線程A發(fā)起一個寫操作,第一步del cache
2.線程A第二步寫入新數(shù)據(jù)到DB
3.線程B發(fā)起一個讀操作,cache miss緩存失效了。
4.線程B從DB獲取最新數(shù)據(jù)
5.線程B執(zhí)行set cache,把從DB讀到的數(shù)據(jù),更新到緩存。
「這樣看,沒啥問題」。
1.線程A發(fā)起一個寫操作,第一步del cache
2.此時線程B發(fā)起一個讀操作,cache miss
3.線程B繼續(xù)讀DB,讀出來一個老數(shù)據(jù)
4.然后老數(shù)據(jù)設(shè)置入cache
5.線程A寫入DB最新的數(shù)據(jù)
OK,醬紫,就有問題了吧,老數(shù)據(jù)入到緩存了,「每次讀都是老數(shù)據(jù)啦,緩存與數(shù)據(jù)與數(shù)據(jù)庫數(shù)據(jù)不一致了」。
緩存維護方案二
上個方案是一讀一寫,如果是雙寫操作,「先操作緩存,在操作數(shù)據(jù)庫」,會怎么樣呢?
1.線程A發(fā)起一個寫操作,第一步set cache
2.線程A第二步寫入新數(shù)據(jù)到DB
3.線程B發(fā)起一個寫操作,set cache
4.線程B第二步寫入新數(shù)據(jù)到DB
「這樣看,也沒啥問題。」
1.線程A發(fā)起一個寫操作,第一步set cache
2.線程B發(fā)起一個寫操作,第一步set cache
3.線程B寫入數(shù)據(jù)庫到DB
4.線程A寫入數(shù)據(jù)庫到DB
執(zhí)行完后,緩存保存的是B操作后的數(shù)據(jù),數(shù)據(jù)庫是A操作后的數(shù)據(jù),「緩存和數(shù)據(jù)庫數(shù)據(jù)不一致了」。
緩存維護方案三
一寫(線程A)一讀(線程B)操作,「先操作數(shù)據(jù)庫,再操作緩存」。
1.線程A發(fā)起一個寫操作,第一步write DB
2.線程A第二步del cache
3.線程B發(fā)起一個讀操作,cache miss
4.線程B從DB獲取最新數(shù)據(jù)
5.線程B同時set cache
有些朋友可能認為,在第2步刪除緩存之前,線程B讀過來呢?這時候,讀到的是緩存老數(shù)據(jù),這個可以認為是正常業(yè)務(wù)邏輯呀,下次再讀取就是正確數(shù)據(jù)了。這種方案「沒有明顯的并發(fā)問題」,但是呢,「步驟二刪除緩存失敗」,還是個問題。不過概率比較小,「優(yōu)于方案一和方案二」,平時工作中也是使用方案三。綜上對比,我們一般采用方案三,但是有沒有完美全解決方案三的弊端的方法呢?
緩存維護方案四
這個是方案三的改進方案,都是先操作數(shù)據(jù)庫再操作緩存
通過數(shù)據(jù)庫的「binlog」來「異步淘汰key」,以mysql為例 可以「使用阿里的canal將binlog日志采集發(fā)送到MQ隊列」里面,然后「通過ACK機制 確認處理」這條更新消息,刪除緩存,保證數(shù)據(jù)緩存一致性。但是呢還有個問題,「如果是主從數(shù)據(jù)庫呢」?
緩存維護方案五
主從DB問題:因為主從DB同步存在延時時間。如果刪除緩存之后,數(shù)據(jù)同步到備庫之前已經(jīng)有請求過來時,「會從備庫中讀到臟數(shù)據(jù)」,如何解決呢?
緩存維護總結(jié)
綜上所述,在分布式系統(tǒng)中,緩存和數(shù)據(jù)庫同時存在時,如果有寫操作的時候,「先操作數(shù)據(jù)庫,再操作緩存」。如下:
1.讀取緩存中是否有相關(guān)數(shù)據(jù)
2.如果緩存中有相關(guān)數(shù)據(jù)value,則返回
3.如果緩存中沒有相關(guān)數(shù)據(jù),則從數(shù)據(jù)庫讀取相關(guān)數(shù)據(jù)放入緩存中key-》value,再返回
4.如果有更新寫數(shù)據(jù),則先操作數(shù)據(jù)庫,再操作緩存
5.為了保證第四步更新緩存成功,使用binlog異步通知操作
6.如果是主從數(shù)據(jù)庫,binglog取自于從庫
7.如果是一主多從,每個從庫都要采集binlog,然后消費端收到最后一臺binlog數(shù)據(jù)才刪除緩存
責(zé)任編輯:haq
-
緩存
+關(guān)注
關(guān)注
1文章
248瀏覽量
27743 -
數(shù)據(jù)庫
+關(guān)注
關(guān)注
7文章
4011瀏覽量
68287 -
分布式系統(tǒng)
+關(guān)注
關(guān)注
0文章
150瀏覽量
19876
原文標題:并發(fā)環(huán)境下,先操作數(shù)據(jù)庫還是先操作緩存?
文章出處:【微信號:DBDevs,微信公眾號:數(shù)據(jù)分析與開發(fā)】歡迎添加關(guān)注!文章轉(zhuǎn)載請注明出處。
發(fā)布評論請先 登錄
分布式數(shù)據(jù)恢復(fù)—Ceph+TiDB數(shù)據(jù)恢復(fù)報告
蜂鳥自定義指令軟件講解和內(nèi)聯(lián)匯編(一)
【節(jié)能學(xué)院】Acrel-1000DP分布式光伏監(jiān)控系統(tǒng)在奉賢平高食品 4.4MW 分布式光伏中應(yīng)用
分布式光伏發(fā)電監(jiān)測系統(tǒng)技術(shù)方案
一鍵部署無損網(wǎng)絡(luò):EasyRoCE助力分布式存儲效能革命
EtherCAT科普系列(15):EtherCAT技術(shù)在分布式測控系統(tǒng)領(lǐng)域應(yīng)用
數(shù)據(jù)庫數(shù)據(jù)恢復(fù)—MongoDB數(shù)據(jù)庫文件丟失的數(shù)據(jù)恢復(fù)案例
SQLSERVER數(shù)據(jù)庫是什么
MySQL數(shù)據(jù)庫是什么
多通道電源管理芯片在分布式能源系統(tǒng)中的優(yōu)化策略
分布式存儲數(shù)據(jù)恢復(fù)—虛擬機上hbase和hive數(shù)據(jù)庫數(shù)據(jù)恢復(fù)案例
不用編程不用聯(lián)網(wǎng),PLC和儀表直接對SQL接數(shù)據(jù)庫,有異常時還可先將數(shù)據(jù)緩存
數(shù)據(jù)庫數(shù)據(jù)恢復(fù)——MongoDB數(shù)據(jù)庫文件拷貝后服務(wù)無法啟動的數(shù)據(jù)恢復(fù)
分布式系統(tǒng)中先操作數(shù)據(jù)庫還是先操作緩存
評論