前言
在分布式系統(tǒng)中,緩存和數(shù)據(jù)庫同時(shí)存在時(shí),如果有寫操作的時(shí)候,先操作數(shù)據(jù)庫還是先操作緩存呢?先思考一下,可能會(huì)存在哪些問題,再往下看。下面我分幾種方案闡述。
緩存維護(hù)方案一
假設(shè)有一寫(線程A)一讀(線程B)操作,先操作緩存,在操作數(shù)據(jù)庫。,如下流程圖所示:
1)線程A發(fā)起一個(gè)寫操作,第一步del cache
2)線程A第二步寫入新數(shù)據(jù)到DB
3)線程B發(fā)起一個(gè)讀操作,cache miss,
4)線程B從DB獲取最新數(shù)據(jù)
5)請(qǐng)求B同時(shí)set cache
這樣看,沒啥問題。我們?cè)倏吹诙€(gè)流程圖,如下:
1)線程A發(fā)起一個(gè)寫操作,第一步del cache
2)此時(shí)線程B發(fā)起一個(gè)讀操作,cache miss
3)線程B繼續(xù)讀DB,讀出來一個(gè)老數(shù)據(jù)
4)然后老數(shù)據(jù)入cache
5)線程A寫入了最新的數(shù)據(jù)
OK,醬紫,就有問題了吧,老數(shù)據(jù)入到緩存了,每次讀都是老數(shù)據(jù)啦,緩存與數(shù)據(jù)與數(shù)據(jù)庫數(shù)據(jù)不一致。
緩存維護(hù)方案二
雙寫操作,先操作緩存,在操作數(shù)據(jù)庫。
1)線程A發(fā)起一個(gè)寫操作,第一步set cache
2)線程A第二步寫入新數(shù)據(jù)到DB
3)線程B發(fā)起一個(gè)寫操作,set cache,
4)線程B第二步寫入新數(shù)據(jù)到DB
這樣看,也沒啥問題。,但是有時(shí)候可能事與愿違,我們?cè)倏吹诙€(gè)流程圖,如下:
1)線程A發(fā)起一個(gè)寫操作,第一步set cache
2)線程B發(fā)起一個(gè)寫操作,第一步setcache
3)線程B寫入數(shù)據(jù)庫到DB
4)線程A寫入數(shù)據(jù)庫到DB
執(zhí)行完后,緩存保存的是B操作后的數(shù)據(jù),數(shù)據(jù)庫是A操作后的數(shù)據(jù),緩存和數(shù)據(jù)庫數(shù)據(jù)不一致。
緩存維護(hù)方案三
一寫(線程A)一讀(線程B)操作,先操作數(shù)據(jù)庫,再操作緩存。
1)線程A發(fā)起一個(gè)寫操作,第一步write DB
2)線程A第二步del cache
3)線程B發(fā)起一個(gè)讀操作,cache miss
4)線程B從DB獲取最新數(shù)據(jù)
5)線程B同時(shí)set cache
這種方案沒有明顯的并發(fā)問題,但是有可能步驟二刪除緩存失敗,雖然概率比較小,優(yōu)于方案一和方案二,平時(shí)工作中也是使用方案三。
綜上對(duì)比,我們一般采用方案三,但是有沒有完美全解決方案三的弊端的方法呢?
緩存維護(hù)方案四
這個(gè)是方案三的改進(jìn)方案,都是先操作數(shù)據(jù)庫再操作緩存,我們來看一下流程圖:
通過數(shù)據(jù)庫的binlog來異步淘汰key,以mysql為例 可以使用阿里的canal將binlog日志采集發(fā)送到MQ隊(duì)列里面,然后通過ACK機(jī)制 確認(rèn)處理這條更新消息,刪除緩存,保證數(shù)據(jù)緩存一致性。
但是呢還有個(gè)問題,如果是主從數(shù)據(jù)庫呢?
緩存維護(hù)方案五
主從DB問題:因?yàn)橹鲝腄B同步存在同時(shí)延時(shí)時(shí)間如果刪除緩存之后,數(shù)據(jù)同步到備庫之前已經(jīng)有請(qǐng)求過來時(shí),會(huì)從備庫中讀到臟數(shù)據(jù),如何解決呢?解決方案如下流程圖:
緩存維護(hù)總結(jié)
綜上所述,在分布式系統(tǒng)中,緩存和數(shù)據(jù)庫同時(shí)存在時(shí),如果有寫操作的時(shí)候,先操作數(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)如果是一主多從,每個(gè)從庫都要采集binlog,然后消費(fèi)端收到最后一臺(tái)binlog數(shù)據(jù)才刪除緩存
-
數(shù)據(jù)庫
+關(guān)注
關(guān)注
7文章
4019瀏覽量
68339 -
分布式系統(tǒng)
+關(guān)注
關(guān)注
0文章
152瀏覽量
19886
發(fā)布評(píng)論請(qǐng)先 登錄
TiDB分布式數(shù)據(jù)庫運(yùn)維實(shí)踐
分布式數(shù)據(jù)恢復(fù)—Ceph+TiDB數(shù)據(jù)恢復(fù)報(bào)告
【節(jié)能學(xué)院】Acrel-1000DP分布式光伏監(jiān)控系統(tǒng)在奉賢平高食品 4.4MW 分布式光伏中應(yīng)用
分布式光伏發(fā)電監(jiān)測(cè)系統(tǒng)技術(shù)方案
Redis緩存的經(jīng)典問題和解決方案
一鍵部署無損網(wǎng)絡(luò):EasyRoCE助力分布式存儲(chǔ)效能革命
Ceph分布式存儲(chǔ)系統(tǒng)解析
EtherCAT科普系列(15):EtherCAT技術(shù)在分布式測(cè)控系統(tǒng)領(lǐng)域應(yīng)用
數(shù)據(jù)庫數(shù)據(jù)恢復(fù)—MongoDB數(shù)據(jù)庫文件丟失的數(shù)據(jù)恢復(fù)案例
PLC數(shù)據(jù)中臺(tái)對(duì)接到MySQL數(shù)據(jù)庫并對(duì)接到生產(chǎn)看板
MySQL數(shù)據(jù)庫是什么
多通道電源管理芯片在分布式能源系統(tǒng)中的優(yōu)化策略
分布式存儲(chǔ)數(shù)據(jù)恢復(fù)—虛擬機(jī)上hbase和hive數(shù)據(jù)庫數(shù)據(jù)恢復(fù)案例
不用編程不用聯(lián)網(wǎng),PLC和儀表直接對(duì)SQL接數(shù)據(jù)庫,有異常時(shí)還可先將數(shù)據(jù)緩存
數(shù)據(jù)庫數(shù)據(jù)恢復(fù)——MongoDB數(shù)據(jù)庫文件拷貝后服務(wù)無法啟動(dòng)的數(shù)據(jù)恢復(fù)
分布式系統(tǒng)中的數(shù)據(jù)庫和緩存操作順序
評(píng)論