分布式之?dāng)?shù)據(jù)庫(kù)和緩存雙寫一致性方案解析(轉(zhuǎn)載于https://www.cnblogs.com/rjzheng/p/9041659.html)

為什么寫這篇文章廊驼?

首先,緩存由于其高并發(fā)和高性能的特性惋砂,已經(jīng)在項(xiàng)目中被廣泛使用妒挎。在讀取緩存方面,大家沒啥疑問(wèn)西饵,都是按照下圖的流程來(lái)進(jìn)行業(yè)務(wù)操作酝掩。

但是在更新緩存方面,對(duì)于更新完數(shù)據(jù)庫(kù)眷柔,是更新緩存呢期虾,還是刪除緩存。又或者是先刪除緩存驯嘱,再更新數(shù)據(jù)庫(kù)镶苞,其實(shí)大家存在很大的爭(zhēng)議。目前沒有一篇全面的博客鞠评,對(duì)這幾種方案進(jìn)行解析茂蚓。于是博主戰(zhàn)戰(zhàn)兢兢,頂著被大家噴的風(fēng)險(xiǎn)谢澈,寫了這篇文章煌贴。

文章結(jié)構(gòu)

本文由以下三個(gè)部分組成

1、講解緩存更新策略

2锥忿、對(duì)每種策略進(jìn)行缺點(diǎn)分析

3牛郑、針對(duì)缺點(diǎn)給出改進(jìn)方案

正文

先做一個(gè)說(shuō)明,從理論上來(lái)說(shuō)敬鬓,給緩存設(shè)置過(guò)期時(shí)間淹朋,是保證最終一致性的解決方案。這種方案下钉答,我們可以對(duì)存入緩存的數(shù)據(jù)設(shè)置過(guò)期時(shí)間础芍,所有的寫操作以數(shù)據(jù)庫(kù)為準(zhǔn),對(duì)緩存操作只是盡最大努力即可数尿。也就是說(shuō)如果數(shù)據(jù)庫(kù)寫成功仑性,緩存更新失敗,那么只要到達(dá)過(guò)期時(shí)間右蹦,則后面的讀請(qǐng)求自然會(huì)從數(shù)據(jù)庫(kù)中讀取新值然后回填緩存诊杆。因此歼捐,接下來(lái)討論的思路不依賴于給緩存設(shè)置過(guò)期時(shí)間這個(gè)方案。

在這里晨汹,我們討論三種更新策略:

先更新數(shù)據(jù)庫(kù)豹储,再更新緩存

先刪除緩存,再更新數(shù)據(jù)庫(kù)

先更新數(shù)據(jù)庫(kù)淘这,再刪除緩存

應(yīng)該沒人問(wèn)我剥扣,為什么沒有先更新緩存,再更新數(shù)據(jù)庫(kù)這種策略铝穷。

(1)先更新數(shù)據(jù)庫(kù)钠怯,再更新緩存

這套方案,大家是普遍反對(duì)的氧骤。為什么呢呻疹?有如下兩點(diǎn)原因。

原因一(線程安全角度)

同時(shí)有請(qǐng)求A和請(qǐng)求B進(jìn)行更新操作筹陵,那么會(huì)出現(xiàn)

(1)線程A更新了數(shù)據(jù)庫(kù)

(2)線程B更新了數(shù)據(jù)庫(kù)

(3)線程B更新了緩存

(4)線程A更新了緩存

這就出現(xiàn)請(qǐng)求A更新緩存應(yīng)該比請(qǐng)求B更新緩存早才對(duì)刽锤,但是因?yàn)榫W(wǎng)絡(luò)等原因,B卻比A更早更新了緩存朦佩。這就導(dǎo)致了臟數(shù)據(jù)并思,因此不考慮。

原因二(業(yè)務(wù)場(chǎng)景角度)

有如下兩點(diǎn):

(1)如果你是一個(gè)寫數(shù)據(jù)庫(kù)場(chǎng)景比較多语稠,而讀數(shù)據(jù)場(chǎng)景比較少的業(yè)務(wù)需求宋彼,采用這種方案就會(huì)導(dǎo)致,數(shù)據(jù)壓根還沒讀到仙畦,緩存就被頻繁的更新输涕,浪費(fèi)性能。

(2)如果你寫入數(shù)據(jù)庫(kù)的值慨畸,并不是直接寫入緩存的莱坎,而是要經(jīng)過(guò)一系列復(fù)雜的計(jì)算再寫入緩存。那么寸士,每次寫入數(shù)據(jù)庫(kù)后檐什,都再次計(jì)算寫入緩存的值,無(wú)疑是浪費(fèi)性能的弱卡。顯然乃正,刪除緩存更為適合。

接下來(lái)討論的就是爭(zhēng)議最大的婶博,先刪緩存瓮具,再更新數(shù)據(jù)庫(kù)。還是先更新數(shù)據(jù)庫(kù),再刪緩存的問(wèn)題搭综。

(2)先刪緩存垢箕,再更新數(shù)據(jù)庫(kù)

該方案會(huì)導(dǎo)致不一致的原因是划栓。同時(shí)有一個(gè)請(qǐng)求A進(jìn)行更新操作兑巾,另一個(gè)請(qǐng)求B進(jìn)行查詢操作。那么會(huì)出現(xiàn)如下情形:

(1)請(qǐng)求A進(jìn)行寫操作忠荞,刪除緩存

(2)請(qǐng)求B查詢發(fā)現(xiàn)緩存不存在

(3)請(qǐng)求B去數(shù)據(jù)庫(kù)查詢得到舊值

(4)請(qǐng)求B將舊值寫入緩存

(5)請(qǐng)求A將新值寫入數(shù)據(jù)庫(kù)

上述情況就會(huì)導(dǎo)致不一致的情形出現(xiàn)蒋歌。而且,如果不采用給緩存設(shè)置過(guò)期時(shí)間策略委煤,該數(shù)據(jù)永遠(yuǎn)都是臟數(shù)據(jù)堂油。

那么,如何解決呢碧绞?采用延時(shí)雙刪策略

偽代碼如下

publicvoidwrite(String key,Object data){? ? ? ? redis.delKey(key);? ? ? ? db.updateData(data);? ? ? ? Thread.sleep(1000);? ? ? ? redis.delKey(key);? ? }

轉(zhuǎn)化為中文描述就是

(1)先淘汰緩存

(2)再寫數(shù)據(jù)庫(kù)(這兩步和原來(lái)一樣)

(3)休眠1秒府框,再次淘汰緩存

這么做,可以將1秒內(nèi)所造成的緩存臟數(shù)據(jù)讥邻,再次刪除迫靖。

那么,這個(gè)1秒怎么確定的兴使,具體該休眠多久呢系宜?

針對(duì)上面的情形,讀者應(yīng)該自行評(píng)估自己的項(xiàng)目的讀數(shù)據(jù)業(yè)務(wù)邏輯的耗時(shí)发魄。然后寫數(shù)據(jù)的休眠時(shí)間則在讀數(shù)據(jù)業(yè)務(wù)邏輯的耗時(shí)基礎(chǔ)上盹牧,加幾百ms即可。這么做的目的励幼,就是確保讀請(qǐng)求結(jié)束汰寓,寫請(qǐng)求可以刪除讀請(qǐng)求造成的緩存臟數(shù)據(jù)。

如果你用了mysql的讀寫分離架構(gòu)怎么辦苹粟?

ok有滑,在這種情況下,造成數(shù)據(jù)不一致的原因如下六水,還是兩個(gè)請(qǐng)求俺孙,一個(gè)請(qǐng)求A進(jìn)行更新操作,另一個(gè)請(qǐng)求B進(jìn)行查詢操作掷贾。

(1)請(qǐng)求A進(jìn)行寫操作睛榄,刪除緩存

(2)請(qǐng)求A將數(shù)據(jù)寫入數(shù)據(jù)庫(kù)了,

(3)請(qǐng)求B查詢緩存發(fā)現(xiàn)想帅,緩存沒有值

(4)請(qǐng)求B去從庫(kù)查詢场靴,這時(shí),還沒有完成主從同步,因此查詢到的是舊值

(5)請(qǐng)求B將舊值寫入緩存

(6)數(shù)據(jù)庫(kù)完成主從同步旨剥,從庫(kù)變?yōu)樾轮?/p>

上述情形咧欣,就是數(shù)據(jù)不一致的原因。還是使用雙刪延時(shí)策略轨帜。只是魄咕,睡眠時(shí)間修改為在主從同步的延時(shí)時(shí)間基礎(chǔ)上,加幾百ms蚌父。

采用這種同步淘汰策略哮兰,吞吐量降低怎么辦?

ok苟弛,那就將第二次刪除作為異步的喝滞。自己起一個(gè)線程,異步刪除膏秫。這樣右遭,寫的請(qǐng)求就不用沉睡一段時(shí)間后了,再返回缤削。這么做窘哈,加大吞吐量。

第二次刪除,如果刪除失敗怎么辦僻他?

這是個(gè)非常好的問(wèn)題宵距,因?yàn)榈诙蝿h除失敗,就會(huì)出現(xiàn)如下情形吨拗。還是有兩個(gè)請(qǐng)求满哪,一個(gè)請(qǐng)求A進(jìn)行更新操作,另一個(gè)請(qǐng)求B進(jìn)行查詢操作劝篷,為了方便哨鸭,假設(shè)是單庫(kù):

(1)請(qǐng)求A進(jìn)行寫操作,刪除緩存

(2)請(qǐng)求B查詢發(fā)現(xiàn)緩存不存在

(3)請(qǐng)求B去數(shù)據(jù)庫(kù)查詢得到舊值

(4)請(qǐng)求B將舊值寫入緩存

(5)請(qǐng)求A將新值寫入數(shù)據(jù)庫(kù)

(6)請(qǐng)求A試圖去刪除請(qǐng)求B寫入對(duì)緩存值娇妓,結(jié)果失敗了像鸡。

ok,這也就是說(shuō)。如果第二次刪除緩存失敗哈恰,會(huì)再次出現(xiàn)緩存和數(shù)據(jù)庫(kù)不一致的問(wèn)題只估。

如何解決呢?

具體解決方案着绷,且看博主對(duì)第(3)種更新策略的解析蛔钙。

(3)先更新數(shù)據(jù)庫(kù),再刪緩存

首先荠医,先說(shuō)一下吁脱。老外提出了一個(gè)緩存更新套路桑涎,名為《Cache-Aside pattern》。其中就指出

失效:應(yīng)用程序先從cache取數(shù)據(jù)兼贡,沒有得到攻冷,則從數(shù)據(jù)庫(kù)中取數(shù)據(jù),成功后遍希,放到緩存中等曼。

命中:應(yīng)用程序從cache中取數(shù)據(jù),取到后返回孵班。

更新:先把數(shù)據(jù)存到數(shù)據(jù)庫(kù)中涉兽,成功后,再讓緩存失效篙程。

另外,知名社交網(wǎng)站facebook也在論文《Scaling Memcache at Facebook》中提出别厘,他們用的也是先更新數(shù)據(jù)庫(kù)虱饿,再刪緩存的策略。

這種情況不存在并發(fā)問(wèn)題么触趴?

不是的氮发。假設(shè)這會(huì)有兩個(gè)請(qǐng)求,一個(gè)請(qǐng)求A做查詢操作冗懦,一個(gè)請(qǐng)求B做更新操作爽冕,那么會(huì)有如下情形產(chǎn)生

(1)緩存剛好失效

(2)請(qǐng)求A查詢數(shù)據(jù)庫(kù),得一個(gè)舊值

(3)請(qǐng)求B將新值寫入數(shù)據(jù)庫(kù)

(4)請(qǐng)求B刪除緩存

(5)請(qǐng)求A將查到的舊值寫入緩存

ok披蕉,如果發(fā)生上述情況颈畸,確實(shí)是會(huì)發(fā)生臟數(shù)據(jù)。

然而没讲,發(fā)生這種情況的概率又有多少呢眯娱?

發(fā)生上述情況有一個(gè)先天性條件,就是步驟(3)的寫數(shù)據(jù)庫(kù)操作比步驟(2)的讀數(shù)據(jù)庫(kù)操作耗時(shí)更短爬凑,才有可能使得步驟(4)先于步驟(5)徙缴。可是嘁信,大家想想于样,數(shù)據(jù)庫(kù)的讀操作的速度遠(yuǎn)快于寫操作的(不然做讀寫分離干嘛,做讀寫分離的意義就是因?yàn)樽x操作比較快潘靖,耗資源少)穿剖,因此步驟(3)耗時(shí)比步驟(2)更短,這一情形很難出現(xiàn)秘豹。

假設(shè)携御,有人非要抬杠,有強(qiáng)迫癥,一定要解決怎么辦啄刹?

如何解決上述并發(fā)問(wèn)題涮坐?

首先,給緩存設(shè)有效時(shí)間是一種方案誓军。其次袱讹,采用策略(2)里給出的異步延時(shí)刪除策略,保證讀請(qǐng)求完成以后昵时,再進(jìn)行刪除操作捷雕。

還有其他造成不一致的原因么?

有的壹甥,這也是緩存更新策略(2)和緩存更新策略(3)都存在的一個(gè)問(wèn)題救巷,如果刪緩存失敗了怎么辦,那不是會(huì)有不一致的情況出現(xiàn)么句柠。比如一個(gè)寫數(shù)據(jù)請(qǐng)求浦译,然后寫入數(shù)據(jù)庫(kù)了,刪緩存失敗了溯职,這會(huì)就出現(xiàn)不一致的情況了精盅。這也是緩存更新策略(2)里留下的最后一個(gè)疑問(wèn)。

如何解決谜酒?

提供一個(gè)保障的重試機(jī)制即可叹俏,這里給出兩套方案。

方案一

如下圖所示

流程如下所示

(1)更新數(shù)據(jù)庫(kù)數(shù)據(jù)僻族;

(2)緩存因?yàn)榉N種問(wèn)題刪除失敗

(3)將需要?jiǎng)h除的key發(fā)送至消息隊(duì)列

(4)自己消費(fèi)消息粘驰,獲得需要?jiǎng)h除的key

(5)繼續(xù)重試刪除操作,直到成功

然而鹰贵,該方案有一個(gè)缺點(diǎn)晴氨,對(duì)業(yè)務(wù)線代碼造成大量的侵入。于是有了方案二碉输,在方案二中籽前,啟動(dòng)一個(gè)訂閱程序去訂閱數(shù)據(jù)庫(kù)的binlog,獲得需要操作的數(shù)據(jù)敷钾。在應(yīng)用程序中枝哄,另起一段程序,獲得這個(gè)訂閱程序傳來(lái)的信息阻荒,進(jìn)行刪除緩存操作挠锥。

方案二

流程如下圖所示:

(1)更新數(shù)據(jù)庫(kù)數(shù)據(jù)

(2)數(shù)據(jù)庫(kù)會(huì)將操作信息寫入binlog日志當(dāng)中

(3)訂閱程序提取出所需要的數(shù)據(jù)以及key

(4)另起一段非業(yè)務(wù)代碼,獲得該信息

(5)嘗試刪除緩存操作侨赡,發(fā)現(xiàn)刪除失敗

(6)將這些信息發(fā)送至消息隊(duì)列

(7)重新從消息隊(duì)列中獲得該數(shù)據(jù)蓖租,重試操作粱侣。

備注說(shuō)明:上述的訂閱binlog程序在mysql中有現(xiàn)成的中間件叫canal,可以完成訂閱binlog日志的功能蓖宦。至于oracle中齐婴,博主目前不知道有沒有現(xiàn)成中間件可以使用。另外稠茂,重試機(jī)制柠偶,博主是采用的是消息隊(duì)列的方式。如果對(duì)一致性要求不是很高睬关,直接在程序中另起一個(gè)線程诱担,每隔一段時(shí)間去重試即可,這些大家可以靈活自由發(fā)揮电爹,只是提供一個(gè)思路蔫仙。

總結(jié)

本文其實(shí)是對(duì)目前互聯(lián)網(wǎng)中已有的一致性方案,進(jìn)行了一個(gè)總結(jié)藐不。對(duì)于先刪緩存拄显,再更新數(shù)據(jù)庫(kù)的更新策略超全,還有方案提出維護(hù)一個(gè)內(nèi)存隊(duì)列的方式,博主看了一下带斑,覺得實(shí)現(xiàn)異常復(fù)雜阱州,沒有必要挑秉,因此沒有必要在文中給出。最后苔货,希望大家有所收獲犀概。

參考文獻(xiàn)

1、主從DB與cache一致性

2夜惭、緩存更新的套路

作者:孤獨(dú)煙?出處:?http://rjzheng.cnblogs.com/

本文版權(quán)歸作者和博客園共有姻灶,歡迎轉(zhuǎn)載,但未經(jīng)作者同意必須保留此段聲明诈茧,且在文章頁(yè)面明顯位置給出原文連接产喉,否則保留追究法律責(zé)任的權(quán)利。如果覺得還有幫助的話敢会,可以點(diǎn)一下右下角的【推薦】曾沈。

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
  • 序言:七十年代末,一起剝皮案震驚了整個(gè)濱河市鸥昏,隨后出現(xiàn)的幾起案子塞俱,更是在濱河造成了極大的恐慌,老刑警劉巖吏垮,帶你破解...
    沈念sama閱讀 222,378評(píng)論 6 516
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件障涯,死亡現(xiàn)場(chǎng)離奇詭異罐旗,居然都是意外死亡,警方通過(guò)查閱死者的電腦和手機(jī)唯蝶,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 94,970評(píng)論 3 399
  • 文/潘曉璐 我一進(jìn)店門九秀,熙熙樓的掌柜王于貴愁眉苦臉地迎上來(lái),“玉大人生棍,你說(shuō)我怎么就攤上這事颤霎。” “怎么了涂滴?”我有些...
    開封第一講書人閱讀 168,983評(píng)論 0 362
  • 文/不壞的土叔 我叫張陵友酱,是天一觀的道長(zhǎng)。 經(jīng)常有香客問(wèn)我柔纵,道長(zhǎng)缔杉,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 59,938評(píng)論 1 299
  • 正文 為了忘掉前任搁料,我火速辦了婚禮或详,結(jié)果婚禮上,老公的妹妹穿的比我還像新娘郭计。我一直安慰自己霸琴,他們只是感情好,可當(dāng)我...
    茶點(diǎn)故事閱讀 68,955評(píng)論 6 398
  • 文/花漫 我一把揭開白布昭伸。 她就那樣靜靜地躺著梧乘,像睡著了一般。 火紅的嫁衣襯著肌膚如雪庐杨。 梳的紋絲不亂的頭發(fā)上选调,一...
    開封第一講書人閱讀 52,549評(píng)論 1 312
  • 那天,我揣著相機(jī)與錄音灵份,去河邊找鬼仁堪。 笑死,一個(gè)胖子當(dāng)著我的面吹牛填渠,可吹牛的內(nèi)容都是我干的弦聂。 我是一名探鬼主播,決...
    沈念sama閱讀 41,063評(píng)論 3 422
  • 文/蒼蘭香墨 我猛地睜開眼揭蜒,長(zhǎng)吁一口氣:“原來(lái)是場(chǎng)噩夢(mèng)啊……” “哼横浑!你這毒婦竟也來(lái)了?” 一聲冷哼從身側(cè)響起屉更,我...
    開封第一講書人閱讀 39,991評(píng)論 0 277
  • 序言:老撾萬(wàn)榮一對(duì)情侶失蹤徙融,失蹤者是張志新(化名)和其女友劉穎,沒想到半個(gè)月后瑰谜,有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體欺冀,經(jīng)...
    沈念sama閱讀 46,522評(píng)論 1 319
  • 正文 獨(dú)居荒郊野嶺守林人離奇死亡树绩,尸身上長(zhǎng)有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點(diǎn)故事閱讀 38,604評(píng)論 3 342
  • 正文 我和宋清朗相戀三年,在試婚紗的時(shí)候發(fā)現(xiàn)自己被綠了隐轩。 大學(xué)時(shí)的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片饺饭。...
    茶點(diǎn)故事閱讀 40,742評(píng)論 1 353
  • 序言:一個(gè)原本活蹦亂跳的男人離奇死亡,死狀恐怖职车,靈堂內(nèi)的尸體忽然破棺而出瘫俊,到底是詐尸還是另有隱情,我是刑警寧澤悴灵,帶...
    沈念sama閱讀 36,413評(píng)論 5 351
  • 正文 年R本政府宣布扛芽,位于F島的核電站,受9級(jí)特大地震影響积瞒,放射性物質(zhì)發(fā)生泄漏川尖。R本人自食惡果不足惜,卻給世界環(huán)境...
    茶點(diǎn)故事閱讀 42,094評(píng)論 3 335
  • 文/蒙蒙 一茫孔、第九天 我趴在偏房一處隱蔽的房頂上張望叮喳。 院中可真熱鬧,春花似錦缰贝、人聲如沸馍悟。這莊子的主人今日做“春日...
    開封第一講書人閱讀 32,572評(píng)論 0 25
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽(yáng)赋朦。三九已至,卻和暖如春李破,著一層夾襖步出監(jiān)牢的瞬間,已是汗流浹背壹将。 一陣腳步聲響...
    開封第一講書人閱讀 33,671評(píng)論 1 274
  • 我被黑心中介騙來(lái)泰國(guó)打工嗤攻, 沒想到剛下飛機(jī)就差點(diǎn)兒被人妖公主榨干…… 1. 我叫王不留,地道東北人诽俯。 一個(gè)月前我還...
    沈念sama閱讀 49,159評(píng)論 3 378
  • 正文 我出身青樓妇菱,卻偏偏與公主長(zhǎng)得像,于是被迫代替她去往敵國(guó)和親暴区。 傳聞我的和親對(duì)象是個(gè)殘疾皇子闯团,可洞房花燭夜當(dāng)晚...
    茶點(diǎn)故事閱讀 45,747評(píng)論 2 361

推薦閱讀更多精彩內(nèi)容