前言
在分布式系統(tǒng)中,緩存和數(shù)據(jù)庫(kù)同時(shí)存在時(shí),如果有寫(xiě)操作,先操作數(shù)據(jù)庫(kù)還是先操作緩存呢?本文將分5種方案展開(kāi)闡述對(duì)比,謝謝閱讀~github地址,衷心感謝每一顆star
?https://github.com/whx123/JavaHome?
緩存維護(hù)方案一
如果是一讀(線(xiàn)程B)一寫(xiě)(線(xiàn)程A)操作,「先操作緩存,再操作數(shù)據(jù)庫(kù)」。流程圖如下所示:
1.線(xiàn)程A發(fā)起一個(gè)寫(xiě)操作,第一步del cache
2.線(xiàn)程A第二步寫(xiě)入新數(shù)據(jù)到DB
3.線(xiàn)程B發(fā)起一個(gè)讀操作,cache miss緩存失效了。
4.線(xiàn)程B從DB獲取最新數(shù)據(jù)
5.線(xiàn)程B執(zhí)行set cache,把從DB讀到的數(shù)據(jù),更新到緩存。
「這樣看,沒(méi)啥問(wèn)題」。
1.線(xiàn)程A發(fā)起一個(gè)寫(xiě)操作,第一步del cache
2.此時(shí)線(xiàn)程B發(fā)起一個(gè)讀操作,cache miss
3.線(xiàn)程B繼續(xù)讀DB,讀出來(lái)一個(gè)老數(shù)據(jù)
4.然后老數(shù)據(jù)設(shè)置入cache
5.線(xiàn)程A寫(xiě)入DB最新的數(shù)據(jù)
OK,醬紫,就有問(wèn)題了吧,老數(shù)據(jù)入到緩存了,「每次讀都是老數(shù)據(jù)啦,緩存與數(shù)據(jù)與數(shù)據(jù)庫(kù)數(shù)據(jù)不一致了」。
緩存維護(hù)方案二
上個(gè)方案是一讀一寫(xiě),如果是雙寫(xiě)操作,「先操作緩存,在操作數(shù)據(jù)庫(kù)」,會(huì)怎么樣呢?
1.線(xiàn)程A發(fā)起一個(gè)寫(xiě)操作,第一步set cache
2.線(xiàn)程A第二步寫(xiě)入新數(shù)據(jù)到DB
3.線(xiàn)程B發(fā)起一個(gè)寫(xiě)操作,set cache
4.線(xiàn)程B第二步寫(xiě)入新數(shù)據(jù)到DB
「這樣看,也沒(méi)啥問(wèn)題。」
1.線(xiàn)程A發(fā)起一個(gè)寫(xiě)操作,第一步set cache
2.線(xiàn)程B發(fā)起一個(gè)寫(xiě)操作,第一步set cache
3.線(xiàn)程B寫(xiě)入數(shù)據(jù)庫(kù)到DB
4.線(xiàn)程A寫(xiě)入數(shù)據(jù)庫(kù)到DB
執(zhí)行完后,緩存保存的是B操作后的數(shù)據(jù),數(shù)據(jù)庫(kù)是A操作后的數(shù)據(jù),「緩存和數(shù)據(jù)庫(kù)數(shù)據(jù)不一致了」。
緩存維護(hù)方案三
一寫(xiě)(線(xiàn)程A)一讀(線(xiàn)程B)操作,「先操作數(shù)據(jù)庫(kù),再操作緩存」。
1.線(xiàn)程A發(fā)起一個(gè)寫(xiě)操作,第一步write DB
2.線(xiàn)程A第二步del cache
3.線(xiàn)程B發(fā)起一個(gè)讀操作,cache miss
4.線(xiàn)程B從DB獲取最新數(shù)據(jù)
5.線(xiàn)程B同時(shí)set cache
有些朋友可能認(rèn)為,在第2步刪除緩存之前,線(xiàn)程B讀過(guò)來(lái)呢?這時(shí)候,讀到的是緩存老數(shù)據(jù),這個(gè)可以認(rèn)為是正常業(yè)務(wù)邏輯呀,下次再讀取就是正確數(shù)據(jù)了。這種方案「沒(méi)有明顯的并發(fā)問(wèn)題」,但是呢,「步驟二刪除緩存失敗」,還是個(gè)問(wèn)題。不過(guò)概率比較小,「優(yōu)于方案一和方案二」,平時(shí)工作中也是使用方案三。綜上對(duì)比,我們一般采用方案三,但是有沒(méi)有完美全解決方案三的弊端的方法呢?
緩存維護(hù)方案四
這個(gè)是方案三的改進(jìn)方案,都是先操作數(shù)據(jù)庫(kù)再操作緩存
通過(guò)數(shù)據(jù)庫(kù)的「binlog」來(lái)「異步淘汰key」,以mysql為例 可以「使用阿里的canal將binlog日志采集發(fā)送到MQ隊(duì)列」里面,然后「通過(guò)ACK機(jī)制 確認(rèn)處理」這條更新消息,刪除緩存,保證數(shù)據(jù)緩存一致性。但是呢還有個(gè)問(wèn)題,「如果是主從數(shù)據(jù)庫(kù)呢」?
緩存維護(hù)方案五
主從DB問(wèn)題:因?yàn)橹鲝腄B同步存在延時(shí)時(shí)間。如果刪除緩存之后,數(shù)據(jù)同步到備庫(kù)之前已經(jīng)有請(qǐng)求過(guò)來(lái)時(shí),「會(huì)從備庫(kù)中讀到臟數(shù)據(jù)」,如何解決呢?
緩存維護(hù)總結(jié)
綜上所述,在分布式系統(tǒng)中,緩存和數(shù)據(jù)庫(kù)同時(shí)存在時(shí),如果有寫(xiě)操作的時(shí)候,「先操作數(shù)據(jù)庫(kù),再操作緩存」。如下:
1.讀取緩存中是否有相關(guān)數(shù)據(jù)
2.如果緩存中有相關(guān)數(shù)據(jù)value,則返回
3.如果緩存中沒(méi)有相關(guān)數(shù)據(jù),則從數(shù)據(jù)庫(kù)讀取相關(guān)數(shù)據(jù)放入緩存中key-》value,再返回
4.如果有更新寫(xiě)數(shù)據(jù),則先操作數(shù)據(jù)庫(kù),再操作緩存
5.為了保證第四步更新緩存成功,使用binlog異步通知操作
6.如果是主從數(shù)據(jù)庫(kù),binglog取自于從庫(kù)
7.如果是一主多從,每個(gè)從庫(kù)都要采集binlog,然后消費(fèi)端收到最后一臺(tái)binlog數(shù)據(jù)才刪除緩存
責(zé)任編輯:haq
-
緩存
+關(guān)注
關(guān)注
1文章
246瀏覽量
27170 -
數(shù)據(jù)庫(kù)
+關(guān)注
關(guān)注
7文章
3926瀏覽量
66208 -
分布式系統(tǒng)
+關(guān)注
關(guān)注
0文章
147瀏覽量
19631
原文標(biāo)題:并發(fā)環(huán)境下,先操作數(shù)據(jù)庫(kù)還是先操作緩存?
文章出處:【微信號(hào):DBDevs,微信公眾號(hào):數(shù)據(jù)分析與開(kāi)發(fā)】歡迎添加關(guān)注!文章轉(zhuǎn)載請(qǐng)注明出處。
發(fā)布評(píng)論請(qǐng)先 登錄
分布式存儲(chǔ)數(shù)據(jù)恢復(fù)—虛擬機(jī)上hbase和hive數(shù)據(jù)庫(kù)數(shù)據(jù)恢復(fù)案例
深入HarmonyOS NEXT開(kāi)發(fā)中的ArkData操作SQLite數(shù)據(jù)庫(kù)
分布式云化數(shù)據(jù)庫(kù)有哪些類(lèi)型
SqlServer數(shù)據(jù)恢復(fù)—SqlServer數(shù)據(jù)庫(kù)數(shù)據(jù)恢復(fù)案例

HarmonyOS Next 應(yīng)用元服務(wù)開(kāi)發(fā)-分布式數(shù)據(jù)對(duì)象遷移數(shù)據(jù)文件資產(chǎn)遷移
HarmonyOS Next 應(yīng)用元服務(wù)開(kāi)發(fā)-分布式數(shù)據(jù)對(duì)象遷移數(shù)據(jù)權(quán)限與基礎(chǔ)數(shù)據(jù)
PingCAP推出TiDB開(kāi)源分布式數(shù)據(jù)庫(kù)

一文講清什么是分布式云化數(shù)據(jù)庫(kù)!
分布式云化數(shù)據(jù)庫(kù)的優(yōu)缺點(diǎn)分析
華納云:MySQL初始化操作如何創(chuàng)建新的數(shù)據(jù)庫(kù)
軟件系統(tǒng)數(shù)據(jù)庫(kù)的分庫(kù)分表設(shè)計(jì)

基于分布式存儲(chǔ)WDS的金融信創(chuàng)云承載數(shù)據(jù)庫(kù)類(lèi)關(guān)鍵應(yīng)用

基于Openharmony輕量級(jí)操作系統(tǒng)的分布式數(shù)據(jù)管理開(kāi)發(fā)案例

評(píng)論