美團二面:Redis與MySQL雙寫一致性如何保證?

碼農談IT發表於2023-02-21

前言

四月份的時候,有位好朋友去美團面試。他說,被問到Redis與MySQL雙寫一致性如何保證?這道題其實就是在問快取和資料庫在雙寫場景下,一致性是如何保證的?本文將跟大家一起來探討如何回答這個問題。

美團二面:Redis與MySQL雙寫一致性如何保證?

  • 公眾號:撿田螺的小男孩

談談一致性

美團二面:Redis與MySQL雙寫一致性如何保證?

一致性就是資料保持一致,在分散式系統中,可以理解為多個節點中資料的值是一致的。

  • 強一致性:這種一致性級別是最符合使用者直覺的,它要求系統寫入什麼,讀出來的也會是什麼,使用者體驗好,但實現起來往往對系統的效能影響大
  • 弱一致性:這種一致性級別約束了系統在寫入成功後,不承諾立即可以讀到寫入的值,也不承諾多久之後資料能夠達到一致,但會盡可能地保證到某個時間級別(比如秒級別)後,資料能夠達到一致狀態
  • 最終一致性:最終一致性是弱一致性的一個特例,系統會保證在一定時間內,能夠達到一個資料一致的狀態。這裡之所以將最終一致性單獨提出來,是因為它是弱一致性中非常推崇的一種一致性模型,也是業界在大型分散式系統的資料一致性上比較推崇的模型

三個經典的快取模式

快取可以提升效能、緩解資料庫壓力,但是使用快取也會導致資料不一致性的問題。一般我們是如何使用快取呢?有三種經典的快取使用模式:

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

Cache-Aside Pattern

Cache-Aside Pattern,即旁路快取模式,它的提出是為了儘可能地解決快取與資料庫的資料不一致問題。

Cache-Aside讀流程

Cache-Aside Pattern的讀請求流程如下:

美團二面:Redis與MySQL雙寫一致性如何保證?
  1. 讀的時候,先讀快取,快取命中的話,直接返回資料
  2. 快取沒有命中的話,就去讀資料庫,從資料庫取出資料,放入快取後,同時返回響應。

Cache-Aside 寫流程

Cache-Aside Pattern的寫請求流程如下:

美團二面:Redis與MySQL雙寫一致性如何保證?

更新的時候,先更新資料庫,然後再刪除快取

Read-Through/Write-Through(讀寫穿透)

Read/Write-Through模式中,服務端把快取作為主要資料儲存。應用程式跟資料庫快取互動,都是透過抽象快取層完成的。

Read-Through

Read-Through的簡要流程如下

美團二面:Redis與MySQL雙寫一致性如何保證?
  1. 從快取讀取資料,讀到直接返回
  2. 如果讀取不到的話,從資料庫載入,寫入快取後,再返回響應。

這個簡要流程是不是跟Cache-Aside很像呢?其實Read-Through就是多了一層Cache-Provider而已,流程如下:

美團二面:Redis與MySQL雙寫一致性如何保證?

Read-Through實際只是在Cache-Aside之上進行了一層封裝,它會讓程式程式碼變得更簡潔,同時也減少資料來源上的負載。

Write-Through

Write-Through模式下,當發生寫請求時,也是由快取抽象層完成資料來源和快取資料的更新,流程如下:美團二面:Redis與MySQL雙寫一致性如何保證?

Write-behind (非同步快取寫入)

Write-behind 跟Read-Through/Write-Through有相似的地方,都是由Cache Provider來負責快取和資料庫的讀寫。它們又有個很大的不同:Read/Write-Through是同步更新快取和資料的,Write-Behind則是隻更新快取,不直接更新資料庫,透過批次非同步的方式來更新資料庫。

美團二面:Redis與MySQL雙寫一致性如何保證?

這種方式下,快取和資料庫的一致性不強,對一致性要求高的系統要謹慎使用。但是它適合頻繁寫的場景,MySQL的InnoDB Buffer Pool機制就使用到這種模式。

操作快取的時候,到底是刪除快取呢,還是更新快取?

日常開發中,我們一般使用的就是Cache-Aside模式。有些小夥伴可能會問, Cache-Aside在寫入請求的時候,為什麼是刪除快取而不是更新快取呢?

美團二面:Redis與MySQL雙寫一致性如何保證?

我們在操作快取的時候,到底應該刪除快取還是更新快取呢?我們先來看個例子:

美團二面:Redis與MySQL雙寫一致性如何保證?
  1. 執行緒A先發起一個寫操作,第一步先更新資料庫
  2. 執行緒B再發起一個寫操作,第二步更新了資料庫
  3. 由於網路等原因,執行緒B先更新了快取
  4. 執行緒A更新快取。

這時候,快取儲存的是A的資料(老資料),資料庫儲存的是B的資料(新資料),資料不一致了,髒資料出現啦。如果是刪除快取取代更新快取則不會出現這個髒資料問題。

更新快取相對於刪除快取,還有兩點劣勢:

  • 如果你寫入的快取值,是經過複雜計算才得到的話。更新快取頻率高的話,就浪費效能啦。
  • 在寫資料庫場景多,讀資料場景少的情況下,資料很多時候還沒被讀取到,又被更新了,這也浪費了效能呢(實際上,寫多的場景,用快取也不是很划算的,哈哈)

雙寫的情況下,先運算元據庫還是先操作快取?

Cache-Aside快取模式中,有些小夥伴還是會有疑問,在寫請求過來的時候,為什麼是先運算元據庫呢?為什麼不先操作快取呢?

假設有A、B兩個請求,請求A做更新操作,請求B做查詢讀取操作。美團二面:Redis與MySQL雙寫一致性如何保證?

  1. 執行緒A發起一個寫操作,第一步del cache
  2. 此時執行緒B發起一個讀操作,cache miss
  3. 執行緒B繼續讀DB,讀出來一個老資料
  4. 然後執行緒B把老資料設定入cache
  5. 執行緒A寫入DB最新的資料

醬紫就有問題啦,快取和資料庫的資料不一致了。快取儲存的是老資料,資料庫儲存的是新資料。因此,Cache-Aside快取模式,選擇了先運算元據庫而不是先操作快取。

  • 個別小夥伴可能會問,先運算元據庫再操作快取,不一樣也會導致資料不一致嘛?它倆又不是原子性操作的。這個是會的,但是這種方式,一般因為刪除快取失敗等原因,才會導致髒資料,這個機率就很低。小夥伴們可以畫下操作流程圖,自己先分析下哈。接下來我們再來分析這種刪除快取失敗的情況,如何保證一致性

資料庫和快取資料保持強一致,可以嘛?

實際上,沒辦法做到資料庫與快取絕對的一致性

  • 加鎖可以嘛?併發寫期間加鎖,任何讀操作不寫入快取?
  • 快取及資料庫封裝CAS樂觀鎖,更新快取時透過lua指令碼?
  • 分散式事務,3PC?TCC?

其實,這是由CAP理論決定的。快取系統適用的場景就是非強一致性的場景,它屬於CAP中的AP。個人覺得,追求絕對一致性的業務場景,不適合引入快取

CAP理論,指的是在一個分散式系統中, Consistency(一致性)、 Availability(可用性)、Partition tolerance(分割槽容錯性),三者不可得兼。

但是,透過一些方案最佳化處理,是可以保證弱一致性,最終一致性的。

3種方案保證資料庫與快取的一致性

快取延時雙刪

有些小夥伴可能會說,並不一定要先運算元據庫呀,採用快取延時雙刪策略,就可以保證資料的一致性啦。什麼是延時雙刪呢?

美團二面:Redis與MySQL雙寫一致性如何保證?
  1. 先刪除快取
  2. 再更新資料庫
  3. 休眠一會(比如1秒),再次刪除快取。

這個休眠一會,一般多久呢?都是1秒?

這個休眠時間 =  讀業務邏輯資料的耗時 + 幾百毫秒。為了確保讀請求結束,寫請求可以刪除讀請求可能帶來的快取髒資料。

這種方案還算可以,只有休眠那一會(比如就那1秒),可能有髒資料,一般業務也會接受的。但是如果第二次刪除快取失敗呢?快取和資料庫的資料還是可能不一致,對吧?給Key設定一個自然的expire過期時間,讓它自動過期怎樣?那業務要接受過期時間內,資料的不一致咯?還是有其他更佳方案呢?

刪除快取重試機制

不管是延時雙刪還是Cache-Aside的先運算元據庫再刪除快取,都可能會存在第二步的刪除快取失敗,導致的資料不一致問題。可以使用這個方案最佳化:刪除失敗就多刪除幾次呀,保證刪除快取成功就可以了呀~ 所以可以引入刪除快取重試機制

美團二面:Redis與MySQL雙寫一致性如何保證?
  1. 寫請求更新資料庫
  2. 快取因為某些原因,刪除失敗
  3. 把刪除失敗的key放到訊息佇列
  4. 消費訊息佇列的訊息,獲取要刪除的key
  5. 重試刪除快取操作

讀取biglog非同步刪除快取

重試刪除快取機制還可以吧,就是會造成好多業務程式碼入侵。其實,還可以這樣最佳化:透過資料庫的binlog來非同步淘汰key

美團二面:Redis與MySQL雙寫一致性如何保證?

以mysql為例吧

  • 可以使用阿里的canal將binlog日誌採集傳送到MQ佇列裡面
  • 然後透過ACK機制確認處理這條更新訊息,刪除快取,保證資料快取一致性


參考與感謝

  • 併發環境下,先運算元據庫還是先操作快取?
  • 高併發場景下,到底先更新快取還是先更新資料庫?
  • 兩難!先更新資料庫再刪快取?還是先刪快取再更新資料庫?
  • 3種快取讀寫策略都不瞭解?面試很難讓你透過啊兄弟

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/70024923/viewspace-2926832/,如需轉載,請註明出處,否則將追究法律責任。

相關文章