美團(tuán)二面：Redis與MySQL雙寫一致性如何保證？

四月份的時(shí)候，有位朋友去美團(tuán)面試，他說(shuō)被問(wèn)到Redis與MySQL雙寫一致性如何保證？ 這道題其實(shí)就是在問(wèn)緩存和數(shù)據(jù)庫(kù)在雙寫場(chǎng)景下，一致性是如何保證的？本文將跟大家一起來(lái)探討如何回答這個(gè)問(wèn)題。

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

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

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

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

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

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

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

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

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

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

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

Write behind跟Read-Through/Write-Through有相似的地方，都是由Cache Provider來(lái)負(fù)責(zé)緩存和數(shù)據(jù)庫(kù)的讀寫。它兩又有個(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)慎使用。但是它適合頻繁寫的場(chǎng)景，MySQL的InnoDB Buffer Pool機(jī)制就使用到這種模式。

一般業(yè)務(wù)場(chǎng)景，我們使用的就是Cache-Aside模式。 有些小伙伴可能會(huì)問(wèn)， Cache-Aside在寫入請(qǐng)求的時(shí)候，為什么是刪除緩存而不是更新緩存呢？

我們?cè)谧骶彺娴臅r(shí)候，到底應(yīng)該刪除緩存還是更新緩存呢？我們先來(lái)看個(gè)例子：

這時(shí)候，緩存保存的是A的數(shù)據(jù)（老數(shù)據(jù)），數(shù)據(jù)庫(kù)保存的是B的數(shù)據(jù)（新數(shù)據(jù)），數(shù)據(jù)不一致了，臟數(shù)據(jù)出現(xiàn)啦。如果是刪除緩存取代更新緩存則不會(huì)出現(xiàn)這個(gè)臟數(shù)據(jù)問(wèn)題。

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

Cache-Aside緩存模式中，有些小伙伴還是有疑問(wèn)，在寫入請(qǐng)求的時(shí)候，為什么是先作數(shù)據(jù)庫(kù)呢？為什么不先作緩存呢？

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

醬紫就有問(wèn)題啦，緩存和數(shù)據(jù)庫(kù)的數(shù)據(jù)不一致了。緩存保存的是老數(shù)據(jù)，數(shù)據(jù)庫(kù)保存的是新數(shù)據(jù)。因此，Cache-Aside緩存模式，選擇了先作數(shù)據(jù)庫(kù)而不是先作緩存。

有些小伙伴可能會(huì)說(shuō)，不一定要先作數(shù)據(jù)庫(kù)呀，采用緩存延時(shí)雙刪策略就好啦？什么是延時(shí)雙刪呢？

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

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

不管是延時(shí)雙刪還是Cache-Aside的先作數(shù)據(jù)庫(kù)再刪除緩存，如果第二步的刪除緩存失敗呢，刪除失敗會(huì)導(dǎo)致臟數(shù)據(jù)哦~

刪除失敗就多刪除幾次呀,保證刪除緩存成功呀~ 所以可以引入刪除緩存重試機(jī)制

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

以mysql為例 可以使用阿里的canal將binlog日志采集發(fā)送到MQ隊(duì)列里面，然后通過(guò)ACK機(jī)制確認(rèn)處理這條更新消息，刪除緩存，保證數(shù)據(jù)緩存一致性