Redis 實戰篇:Redis 與 MySQL 雙寫一致性如何保證?
前言
四月份的時候,有位好朋友去美團面試。他說,被問到 Redis 與 MySQL 雙寫一致性如何保證?這道題其實就是在問緩存和數據庫在雙寫場景下,一致性是如何保證的?本文將跟大家一起來探討如何回答這個問題。
- 公衆號:撿田螺的小男孩
談談一致性
一致性就是數據保持一致,在分佈式系統中,可以理解爲多個節點中數據的值是一致的。
-
強一致性:這種一致性級別是最符合用戶直覺的,它要求系統寫入什麼,讀出來的也會是什麼,用戶體驗好,但實現起來往往對系統的性能影響大
-
弱一致性:這種一致性級別約束了系統在寫入成功後,不承諾立即可以讀到寫入的值,也不承諾多久之後數據能夠達到一致,但會盡可能地保證到某個時間級別(比如秒級別)後,數據能夠達到一致狀態
-
最終一致性:最終一致性是弱一致性的一個特例,系統會保證在一定時間內,能夠達到一個數據一致的狀態。這裏之所以將最終一致性單獨提出來,是因爲它是弱一致性中非常推崇的一種一致性模型,也是業界在大型分佈式系統的數據一致性上比較推崇的模型
三個經典的緩存模式
緩存可以提升性能、緩解數據庫壓力,但是使用緩存也會導致數據不一致性的問題。一般我們是如何使用緩存呢?有三種經典的緩存使用模式:
-
Cache-Aside Pattern
-
Read-Through/Write-through
-
Write-behind
Cache-Aside Pattern
Cache-Aside Pattern,即旁路緩存模式,它的提出是爲了儘可能地解決緩存與數據庫的數據不一致問題。
Cache-Aside 讀流程
Cache-Aside Pattern 的讀請求流程如下:
Cache-Aside 讀請求
-
讀的時候,先讀緩存,緩存命中的話,直接返回數據
-
緩存沒有命中的話,就去讀數據庫,從數據庫取出數據,放入緩存後,同時返回響應。
Cache-Aside 寫流程
Cache-Aside Pattern 的寫請求流程如下:
Cache-Aside 寫請求
更新的時候,先更新數據庫,然後再刪除緩存。
Read-Through/Write-Through(讀寫穿透)
Read/Write-Through 模式中,服務端把緩存作爲主要數據存儲。應用程序跟數據庫緩存交互,都是通過抽象緩存層完成的。
Read-Through
Read-Through 的簡要流程如下
Read-Through 簡要流程
-
從緩存讀取數據,讀到直接返回
-
如果讀取不到的話,從數據庫加載,寫入緩存後,再返回響應。
這個簡要流程是不是跟 Cache-Aside 很像呢?其實 Read-Through 就是多了一層 Cache-Provider 而已,流程如下:
Read-Through 流程
Read-Through 實際只是在 Cache-Aside 之上進行了一層封裝,它會讓程序代碼變得更簡潔,同時也減少數據源上的負載。
Write-Through
Write-Through 模式下,當發生寫請求時,也是由緩存抽象層完成數據源和緩存數據的更新, 流程如下:
Write-behind (異步緩存寫入)
Write-behind 跟 Read-Through/Write-Through 有相似的地方,都是由 Cache Provider 來負責緩存和數據庫的讀寫。它們又有個很大的不同:Read/Write-Through 是同步更新緩存和數據的,Write-Behind 則是隻更新緩存,不直接更新數據庫,通過批量異步的方式來更新數據庫。
Write behind 流程
這種方式下,緩存和數據庫的一致性不強,對一致性要求高的系統要謹慎使用。但是它適合頻繁寫的場景,MySQL 的 InnoDB Buffer Pool 機制就使用到這種模式。
操作緩存的時候,到底是刪除緩存呢,還是更新緩存?
日常開發中,我們一般使用的就是 Cache-Aside 模式。有些小夥伴可能會問, Cache-Aside 在寫入請求的時候,爲什麼是刪除緩存而不是更新緩存呢?
Cache-Aside 寫入流程
我們在操作緩存的時候,到底應該刪除緩存還是更新緩存呢?我們先來看個例子:
-
線程 A 先發起一個寫操作,第一步先更新數據庫
-
線程 B 再發起一個寫操作,第二步更新了數據庫
-
由於網絡等原因,線程 B 先更新了緩存
-
線程 A 更新緩存。
這時候,緩存保存的是 A 的數據(老數據),數據庫保存的是 B 的數據(新數據),數據不一致了,髒數據出現啦。如果是刪除緩存取代更新緩存則不會出現這個髒數據問題。
更新緩存相對於刪除緩存,還有兩點劣勢:
-
如果你寫入的緩存值,是經過複雜計算纔得到的話。更新緩存頻率高的話,就浪費性能啦。
-
在寫數據庫場景多,讀數據場景少的情況下,數據很多時候還沒被讀取到,又被更新了,這也浪費了性能呢 (實際上,寫多的場景,用緩存也不是很划算的, 哈哈)
雙寫的情況下,先操作數據庫還是先操作緩存?
Cache-Aside
緩存模式中,有些小夥伴還是會有疑問,在寫請求過來的時候,爲什麼是先操作數據庫呢?爲什麼不先操作緩存呢?
假設有 A、B 兩個請求,請求 A 做更新操作,請求 B 做查詢讀取操作。
-
線程 A 發起一個寫操作,第一步 del cache
-
此時線程 B 發起一個讀操作,cache miss
-
線程 B 繼續讀 DB,讀出來一個老數據
-
然後線程 B 把老數據設置入 cache
-
線程 A 寫入 DB 最新的數據
醬紫就有問題啦,緩存和數據庫的數據不一致了。緩存保存的是老數據,數據庫保存的是新數據。因此,Cache-Aside 緩存模式,選擇了先操作數據庫而不是先操作緩存。
- 個別小夥伴可能會問,先操作數據庫再操作緩存,不一樣也會導致數據不一致嘛?它倆又不是原子性操作的。這個是會的,但是這種方式,一般因爲刪除緩存失敗等原因,纔會導致髒數據,這個概率就很低。小夥伴們可以畫下操作流程圖,自己先分析下哈。接下來我們再來分析這種刪除緩存失敗的情況,如何保證一致性。
數據庫和緩存數據保持強一致,可以嘛?
實際上,沒辦法做到數據庫與緩存絕對的一致性。
-
加鎖可以嘛?併發寫期間加鎖,任何讀操作不寫入緩存?
-
緩存及數據庫封裝 CAS 樂觀鎖,更新緩存時通過 lua 腳本?
-
分佈式事務,3PC?TCC?
其實,這是由 CAP 理論決定的。緩存系統適用的場景就是非強一致性的場景,它屬於 CAP 中的 AP。個人覺得,追求絕對一致性的業務場景,不適合引入緩存。
★
CAP 理論,指的是在一個分佈式系統中, Consistency(一致性)、 Availability(可用性)、Partition tolerance(分區容錯性),三者不可得兼。
”
但是,通過一些方案優化處理,是可以保證弱一致性,最終一致性的。
3 種方案保證數據庫與緩存的一致性
緩存延時雙刪
有些小夥伴可能會說,並不一定要先操作數據庫呀,採用緩存延時雙刪策略,就可以保證數據的一致性啦。什麼是延時雙刪呢?
延時雙刪流程
-
先刪除緩存
-
再更新數據庫
-
休眠一會(比如 1 秒),再次刪除緩存。
這個休眠一會,一般多久呢?都是 1 秒?
★
這個休眠時間 = 讀業務邏輯數據的耗時 + 幾百毫秒。爲了確保讀請求結束,寫請求可以刪除讀請求可能帶來的緩存髒數據。
”
這種方案還算可以,只有休眠那一會(比如就那 1 秒),可能有髒數據,一般業務也會接受的。但是如果第二次刪除緩存失敗呢?緩存和數據庫的數據還是可能不一致,對吧?給 Key 設置一個自然的 expire 過期時間,讓它自動過期怎樣?那業務要接受過期時間內,數據的不一致咯?還是有其他更佳方案呢?
刪除緩存重試機制
不管是延時雙刪還是 Cache-Aside 的先操作數據庫再刪除緩存,都可能會存在第二步的刪除緩存失敗,導致的數據不一致問題。可以使用這個方案優化:刪除失敗就多刪除幾次呀, 保證刪除緩存成功就可以了呀~ 所以可以引入刪除緩存重試機制
刪除緩存重試流程
-
寫請求更新數據庫
-
緩存因爲某些原因,刪除失敗
-
把刪除失敗的 key 放到消息隊列
-
消費消息隊列的消息,獲取要刪除的 key
-
重試刪除緩存操作
讀取 biglog 異步刪除緩存
重試刪除緩存機制還可以吧,就是會造成好多業務代碼入侵。其實,還可以這樣優化:通過數據庫的 binlog 來異步淘汰 key。
以 mysql 爲例吧
-
可以使用阿里的 canal 將 binlog 日誌採集發送到 MQ 隊列裏面
-
然後通過 ACK 機制確認處理這條更新消息,刪除緩存,保證數據緩存一致性
本文由 Readfog 進行 AMP 轉碼,版權歸原作者所有。
來源:https://mp.weixin.qq.com/s/GEDsNLM1Yj-X4K1pE-1mTw