聊一聊Redis與MySQL雙寫(xiě)一致性如何保證

1 什么是一致性？

一致性就是數(shù)據(jù)保持一致，在分布式系統(tǒng)中，可以理解為多個(gè)節(jié)點(diǎn)中數(shù)據(jù)的值是一致的。

強(qiáng)一致性： 這種一致性級(jí)別是最符合用戶直覺(jué)的，它要求系統(tǒng)寫(xiě)入什么，讀出來(lái)的也會(huì)是什么，用戶體驗(yàn)性好，但實(shí)現(xiàn)起來(lái)往往對(duì)系統(tǒng)的性能影響大；

弱一致性： 這種一致性級(jí)別約束了系統(tǒng)在寫(xiě)入成功后，不承諾立即可以讀到寫(xiě)入的值，也不承諾多久之后數(shù)據(jù)能夠達(dá)到一致，但會(huì)盡可能地保證到某個(gè)時(shí)間級(jí)別(比如秒級(jí)別)后，數(shù)據(jù)能夠達(dá)到一致?tīng)顟B(tài)；

最終一致性： 最終一致性是弱一致性的一個(gè)特例，系統(tǒng)會(huì)保證在一定時(shí)間內(nèi)，能夠達(dá)到一個(gè)數(shù)據(jù)一致的狀態(tài)。這里之所以將最終一致性單獨(dú)提出來(lái)，是因?yàn)樗侨跻恢滦灾蟹浅Ｍ瞥绲囊环N一致性模型，也是業(yè)界在大型分布式系統(tǒng)的數(shù)據(jù)一致性上比較推崇的模型；

 2 三個(gè)經(jīng)典的緩存模式

緩存可以提升性能、緩解數(shù)據(jù)庫(kù)壓力，但是使用緩存也會(huì)導(dǎo)致數(shù)據(jù)不一致性的問(wèn)題。一般我們是如何使用緩存呢？有三種經(jīng)典的緩存使用模式：

• Cache-Aside Pattern；
• Read-Through / Write-Through
• Write-behind

(1) Cache-Aside

Cache-Aside Pattern, 即旁路緩存模式。它的提出是為了盡可能地解決緩存與數(shù)據(jù)庫(kù)的數(shù)據(jù)不一致問(wèn)題。

a. Cache-Aside讀流程

Cache-Aside Pattern的讀請(qǐng)求流程如下：

讀的時(shí)候，先讀緩存，緩存命中的話，直接返回?cái)?shù)據(jù)；緩存沒(méi)有命中的話，就去讀數(shù)據(jù)庫(kù)，從數(shù)據(jù)庫(kù)中取出數(shù)據(jù)，放入緩存后，同時(shí)返回響應(yīng)； b.Cache-Aside寫(xiě)流程

Cache-Aside Pattern的寫(xiě)請(qǐng)求流程如下：

更新得到時(shí)候，先更新數(shù)據(jù)庫(kù)，然后再刪除緩存。

當(dāng)這個(gè)數(shù)據(jù)在下一次需要的時(shí)候，使用Cache-Aside模式將會(huì)在獲取數(shù)據(jù)的時(shí)候，同時(shí)從數(shù)據(jù)倉(cāng)庫(kù)中獲取數(shù)據(jù)，并且寫(xiě)到Cache之中。

(2) Read-Through/Write-Through（讀寫(xiě)穿透）

Read/Write - Through模式中，服務(wù)端把緩存作為主要數(shù)據(jù)存儲(chǔ)。應(yīng)用程序跟數(shù)據(jù)庫(kù)緩存交互，都是通過(guò)抽象緩存層完成的。

a.Read-Through

Read-Through讀的簡(jiǎn)要流程如下：

從緩存中讀取數(shù)據(jù)，讀到直接返回；

如果讀取不到的話，從數(shù)據(jù)庫(kù)中加載，寫(xiě)入緩存后，再返回響應(yīng)；

這個(gè)簡(jiǎn)要流程是不是跟Cache-Aside很像呢？其實(shí)Read-Through就是多了一層Cache-Provider而已，流程如下：

Read-Through 實(shí)際上只是在Cache-Aside之上進(jìn)行了一層封裝，它會(huì)讓程序代碼變得更加簡(jiǎn)潔，同時(shí)也減少數(shù)據(jù)源上的負(fù)載。

b.Write-Through

Write-Through模式下，當(dāng)發(fā)生寫(xiě)請(qǐng)求時(shí)，也是由緩存抽象層完成數(shù)據(jù)源和緩存數(shù)據(jù)的更新，流程如下：

(3) Write-behind（異步緩存寫(xiě)入）

Write-behind跟Read-Through/Write-Through有很多相似的地方，都是由Cache Provider來(lái)負(fù)責(zé)緩存和數(shù)據(jù)庫(kù)的讀寫(xiě)。它們又有個(gè)很大的不同：Read/Write-Through是同步更新緩存和數(shù)據(jù)的，Write-Behind則是只更新緩存，不直接更新數(shù)據(jù)庫(kù)，通過(guò)批量異步的方式來(lái)更新數(shù)據(jù)庫(kù)。

這種方式下，緩存和數(shù)據(jù)庫(kù)的一致性不強(qiáng)，對(duì)一致性要求高的系統(tǒng)要謹(jǐn)慎使用。

但是它適合頻繁寫(xiě)的場(chǎng)景，MySQL的Innodb Buffer Pool機(jī)制就是用到這種模式。

3 操作緩存的時(shí)候，到底是刪除緩存呢，還是更新緩存？

日常開(kāi)發(fā)中，我們一般使用的就是Cache-Aside模式。但這里我們注意到Cache-Aside在寫(xiě)入請(qǐng)求的時(shí)候，為什么是刪除緩存而不是更新緩存呢？

我們?cè)诓僮骶彺娴臅r(shí)候，到底應(yīng)該刪除緩存還是更新緩存呢？這里通過(guò)一個(gè)例子來(lái)說(shuō)明一下：

線程A先發(fā)起一個(gè)寫(xiě)操作，第一步先更新數(shù)據(jù)庫(kù)；線程B先發(fā)起一個(gè)寫(xiě)操作，第二步后更新數(shù)據(jù)庫(kù)；但是由于網(wǎng)絡(luò)等原因，線程B先更新了緩存；線程A更新緩存；

此外, 更新緩存相對(duì)于刪除緩存，還有兩點(diǎn)劣勢(shì)：

如果你寫(xiě)入的緩存值，是經(jīng)過(guò)復(fù)雜計(jì)算才得到的話，更新緩存頻率高的話，就浪費(fèi)性能了；在寫(xiě)數(shù)據(jù)庫(kù)場(chǎng)景多、讀數(shù)據(jù)場(chǎng)景少的情況下，數(shù)據(jù)很多時(shí)候還沒(méi)被讀取到，又被更新了，這也浪費(fèi)了性能呢。 4 雙寫(xiě)的情況下，先操作數(shù)據(jù)庫(kù)還是先操作緩存呢？

Cache-Aside緩存模式中，有些小伙伴還是會(huì)有疑問(wèn)，在寫(xiě)請(qǐng)求過(guò)來(lái)的時(shí)候，為什么是先操作數(shù)據(jù)庫(kù)呢？為什么不先操作緩存呢？

例子：假設(shè)有A、B兩個(gè)請(qǐng)求，請(qǐng)求A做更新操作，請(qǐng)求B做查詢讀取操作。

線程A發(fā)起一個(gè)寫(xiě)操作，第一步del cache；此時(shí)線程B發(fā)起一個(gè)讀操作，cache miss；線程B繼續(xù)讀DB，讀出來(lái)一個(gè)老數(shù)據(jù)，此時(shí)線程B把老數(shù)據(jù)設(shè)置入cache；線程A寫(xiě)入DB更新數(shù)據(jù)；

這里就存在這樣的一個(gè)問(wèn)題了：緩存和數(shù)據(jù)庫(kù)的數(shù)據(jù)不一致了。緩存保存的是老數(shù)據(jù)，數(shù)據(jù)庫(kù)保存的是新數(shù)據(jù)。 因此，Cache-Aside緩存模式，選擇了先操作數(shù)據(jù)庫(kù)而不是先操作緩存。

但可能這時(shí)候有小伙伴會(huì)思考：先操作數(shù)據(jù)庫(kù)再操作緩存，不一樣也會(huì)導(dǎo)致不一致嘛？它倆又不是原子性操作的。這個(gè)是會(huì)的。但是這種方式，一般會(huì)因?yàn)閯h除緩存失敗等原因，才會(huì)導(dǎo)致臟數(shù)據(jù)，這個(gè)概率就很低。

那么針對(duì)這種刪除緩存失敗的情況，如何保證一致性呢？

數(shù)據(jù)庫(kù)和緩存數(shù)據(jù)保持強(qiáng)一致，可以嘛？

實(shí)際上，沒(méi)辦法做到數(shù)據(jù)庫(kù)和緩存的絕對(duì)的一致性。

加鎖可以嘛？并發(fā)寫(xiě)期間加鎖，任何讀操作不寫(xiě)入緩存？緩存以及數(shù)據(jù)庫(kù)封裝CAS樂(lè)觀鎖，更新緩存時(shí)通過(guò)lua腳本？分布式事務(wù)，3PC?TCC？

其實(shí)，這是由CAP理論 決定的。緩存系統(tǒng)適用的場(chǎng)景就是非強(qiáng)一致性的場(chǎng)景，它屬于CAP中的AP 。個(gè)人覺(jué)得，追求絕對(duì)一致性的業(yè)務(wù)場(chǎng)景，不適合引入緩存。

CAP理論，指的是在一個(gè)分布式戲中，Consistency（一致性）、Availability（可用性）、Partition tolerance（分區(qū)容錯(cuò)性）。三者不可兼得

5 幾種方案保證數(shù)據(jù)庫(kù)與緩存的一致性 (1) 緩存延時(shí)雙刪

有些小伙伴可能會(huì)說(shuō)，并不一定要先操作數(shù)據(jù)庫(kù)呀，采用緩存延時(shí)雙刪策略，就可以保證數(shù)據(jù)的一致性拉。那么什么是延時(shí)雙刪呢？

先刪除緩存；再更新數(shù)據(jù)庫(kù)；再休眠一會(huì)(比如1秒)，再次刪除緩存；

那么這個(gè)休眠一會(huì)，一般多久呢？都是1秒？

這個(gè)休眠時(shí)間 = 讀業(yè)務(wù)邏輯數(shù)據(jù)的耗時(shí) + 幾百毫秒。 為了確保讀請(qǐng)求結(jié)束，寫(xiě)請(qǐng)求可以刪除讀請(qǐng)求可能帶來(lái)的緩存臟數(shù)據(jù)；

這種方案還算可以，只有休眠那一會(huì)（比如就那1秒），可能有臟數(shù)據(jù)，一般業(yè)務(wù)也會(huì)接受的。但是如果第二次刪除緩存失敗呢？緩存和數(shù)據(jù)庫(kù)的數(shù)據(jù)還是可能不一致，對(duì)吧？給Key設(shè)置一個(gè)自然的expire過(guò)期時(shí)間，讓它自動(dòng)過(guò)期怎樣？那業(yè)務(wù)要接受過(guò)期時(shí)間內(nèi)，數(shù)據(jù)的不一致咯？還是有其他更佳方案呢？

(2) 刪除緩存重試機(jī)制

不管是延時(shí)雙刪還是Cache-Aside的先操作數(shù)據(jù)庫(kù)再刪除緩存， 都可能會(huì)存在第二步的刪除緩存失敗，導(dǎo)致的數(shù)據(jù)不一致問(wèn)題。可以使用這個(gè)方案優(yōu)化：刪除失敗就多刪除幾次呀，保證刪除緩存成功就可以了呀~ 所以可以引入刪除緩存重試機(jī)制。

寫(xiě)請(qǐng)求更新數(shù)據(jù)庫(kù)；緩存因?yàn)槟承┰?，刪除失敗；把刪除失敗的key放到消息隊(duì)列；消費(fèi)消息隊(duì)列的消息，獲取要?jiǎng)h除的key；重試刪除緩存操作； (3) 讀取binlog異步刪除緩存

重試刪除緩存機(jī)制還可以，但是會(huì)造成好多業(yè)務(wù)代碼入侵。其實(shí)，還可以這樣優(yōu)化：通過(guò)數(shù)據(jù)庫(kù)的binlog來(lái)異步淘汰key。

以上就是Redis與MySQL雙寫(xiě)一致性如何保證呢的詳細(xì)內(nèi)容，更多關(guān)于Redis與MySQL雙寫(xiě)一致性的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！