search
分散式系統事務一致性解決方案

分散式系統事務一致性解決方案

寫在前面

在OLTP系統領域,我們在很多業務場景下都會面臨事務一致性方面的需求,例如最經典的Bob給Smith轉賬的案例。傳統的企業開發,系統往往是以單體應用形式存在的,也沒有橫跨多個資料庫。我們通常只需藉助開發平台中特有數據訪問技術和框架(例如Spring、JDBC、ADO.NET),結合關係型資料庫自帶的事務管理機制來實現事務性的需求。關係型資料庫通常具有ACID特性:原子性(Atomicity)、一致性(Consistency)、隔離性(Isolation)、持久性(Durability)。

而大型互聯網平台往往是由一系列分散式系統構成的,開發語言平台和技術棧也相對比較雜,尤其是在SOA和微服務架構盛行的今天,一個看起來簡單的功能,內部可能需要調用多個「服務」並操作多個資料庫或分片來實現,情況往往會複雜很多。單一的技術手段和解決方案,已經無法應對和滿足這些複雜的場景了。

分散式系統的特性

對分散式系統有過研究的讀者,可能聽說過「CAP定律」、「Base理論」等,非常巧的是,化學理論中ACID是酸、Base恰好是鹼。這裡筆者不對這些概念做過多的解釋,有興趣的讀者可以查看相關參考資料。CAP定律如下圖:

在分散式系統中,同時滿足「CAP定律」中的「一致性」、「可用性」和「分區容錯性」三者是不可能的,這比現實中找對象需同時滿足「高、富、帥」或「白、富、美」更加困難。在互聯網領域的絕大多數的場景,都需要犧牲強一致性來換取系統的高可用性,系統往往只需要保證「最終一致性」,只要這個最終時間是在用戶可以接受的範圍內即可。

分散式事務

提到分散式系統,必然要提到分散式事務。要想理解分散式事務,不得不先介紹一下兩階段提交協議。先舉個簡單但不精準的例子來說明:

第一階段,張老師作為「協調者」,給小強和小明(參與者、節點)發微信,組織他們倆明天8點在學校門口集合,一起去爬山,然後開始等待小強和小明答覆。

第二階段,如果小強和小明都回答沒問題,那麼大家如約而至。如果小強或者小明其中一人回答說「明天沒空,不行」,那麼張老師會立即通知小強和小明「爬山活動取消」。

細心的讀者會發現,這個過程中可能有很多問題的。如果小強沒看手機,那麼張老師會一直等著答覆,小明可能在家裡把爬山裝備都準備好了卻一直等著張老師確認信息。更嚴重的是,如果到明天8點小強還沒有答覆,那麼就算「超時」了,那小明到底去還是不去集合爬山呢?

這就是兩階段提交協議的弊病,所以後來業界又引入了三階段提交協議來解決該類問題。

兩階段提交協議在主流開發語言平台,資料庫產品中都有廣泛應用和實現的,下面來介紹一下XOpen組織提供的DTP模型圖:

XA協議指的是TM(事務管理器)和RM(資源管理器)之間的介面。目前主流的關係型資料庫產品都是實現了XA介面的。JTA(Java Transaction API)是符合X/Open DTP模型的,事務管理器和資源管理器之間也使用了XA協議。 本質上也是藉助兩階段提交協議來實現分散式事務的,下面分別來看看XA事務成功和失敗的模型圖:

在JavaEE平台下,WebLogic、Webshare等主流商用的應用伺服器提供了JTA的實現和支持。而在Tomcat下是沒有實現的(其實筆者並不認為Tomcat能算是JavaEE應用伺服器),這就需要藉助第三方的框架Jotm、Atomikos等來實現,兩者均支持spring事務整合。

而在Windows .NET平台中,則可以藉助ado.net中的TransactionScop API來編程實現,還必須配置和藉助Windows操作系統中的MSDTC服務。如果你的資料庫使用的mysql,並且mysql是部署在Linux平台上的,那麼是無法支持分散式事務的。 由於篇幅關係,這裡不展開,感興趣的讀者可以自行查閱相關資料並實踐。

總結:這種方式實現難度不算太高,比較適合傳統的單體應用,在同一個方法中存在跨庫操作的情況。但分散式事務對性能的影響會比較大,不適合高併發和高性能要求的場景。

提供回滾介面

在服務化架構中,功能X,需要去協調後端的A、B甚至更多的原子服務。那麼問題來了,假如A和B其中一個調用失敗了,那可怎麼辦呢?

在筆者的工作中經常遇到這類問題,往往提供了一個BFF層來協調調用A、B服務。如果有些是需要同步返回結果的,我會盡量按照「串列」的方式去調用。如果調用A失敗,則不會盲目去調用B。如果調用A成功,而調用B失敗,會嘗試去回滾剛剛對A的調用操作。

當然,有些時候我們不必嚴格提供單獨對應的回滾介面,可以通過傳遞參數巧妙的實現。

這樣的情況,我們會盡量把可提供回滾介面的服務放在前面。舉個例子說明:

我們的某個論壇網站,每天登錄成功後會獎勵用戶5個積分,但是積分和用戶又是兩套獨立的子系統服務,對應不同的DB,這控制起來就比較麻煩了。解決思路:

  • 把登錄和加積分的服務調用放在BFF層一個本地方法中。

  • 當用戶請求登錄介面時,先執行加積分操作,加分成功后再執行登錄操作

  • 如果登錄成功,那當然最好了,積分也加成功了。如果登錄失敗,則調用加積分對應的回滾介面(執行減積分的操作)。

總結:這種方式缺點比較多,通常在複雜場景下是不推薦使用的,除非是非常簡單的場景,非常容易提供回滾,而且依賴的服務也非常少的情況。

這種實現方式會造成代碼量龐大,耦合性高。而且非常有局限性,因為有很多的業務是無法很簡單的實現回滾的,如果串列的服務很多,回滾的成本實在太高。

本地消息表

這種實現方式的思路,其實是源於ebay,後來通過支付寶等公司的佈道,在業內廣泛使用。其基本的設計思想是將遠程分散式事務拆分成一系列的本地事務。如果不考慮性能及設計優雅,藉助關係型資料庫中的表即可實現。

舉個經典的跨行轉賬的例子來描述。

第一步偽代碼如下,扣款1W,通過本地事務保證了憑證消息插入到消息表中。

第二步,通知對方銀行賬戶上加1W了。那問題來了,如何通知到對方呢?

通常採用兩種方式:

  • 採用時效性高的MQ,由對方訂閱消息並監聽,有消息時自動觸發事件

  • 採用定時輪詢掃描的方式,去檢查消息表的數據

兩種方式其實各有利弊,僅僅依靠MQ,可能會出現通知失敗的問題。而過於頻繁的定時輪詢,效率也不是最佳的(90%是無用功)。所以,我們一般會把兩種方式結合起來使用。

解決了通知的問題,又有新的問題了。萬一這消息有重複被消費,往用戶帳號上多加了錢,那豈不是後果很嚴重?

仔細思考,其實我們可以消息消費方,也通過一個「消費狀態表」來記錄消費狀態。在執行「加款」操作之前,檢測下該消息(提供標識)是否已經消費過,消費完成後,通過本地事務控制來更新這個「消費狀態表」。這樣子就避免重複消費的問題。

總結:上訴的方式是一種非常經典的實現,基本避免了分散式事務,實現了「最終一致性」。但是,關係型資料庫的吞吐量和性能方面存在瓶頸,頻繁的讀寫消息會給資料庫造成壓力。所以,在真正的高併發場景下,該方案也會有瓶頸和限制的。

MQ(非事務消息)

通常情況下,在使用非事務消息支持的MQ產品時,我們很難將業務操作與對MQ的操作放在一個本地事務域中管理。通俗點描述,還是以上述提到的「跨行轉賬」為例,我們很難保證在扣款完成之後對MQ投遞消息的操作就一定能成功。這樣一致性似乎很難保證。

先從消息生產者這端來分析,請看偽代碼:

根據上述代碼及註釋,我們來分析下可能的情況:

  • 操作資料庫成功,向MQ中投遞消息也成功,皆大歡喜

  • 操作資料庫失敗,不會向MQ中投遞消息了

  • 操作資料庫成功,但是向MQ中投遞消息時失敗,向外拋出了異常,剛剛執行的更新資料庫的操作將被回滾

從上面分析的幾種情況來看,貌似問題都不大的。那麼我們來分析下消費者端面臨的問題:

  • 消息出列后,消費者對應的業務操作要執行成功。如果業務執行失敗,消息不能失效或者丟失。需要保證消息與業務操作一致

  • 盡量避免消息重複消費。如果重複消費,也不能因此影響業務結果

如何保證消息與業務操作一致,不丟失?

主流的MQ產品都具有持久化消息的功能。如果消費者宕機或者消費失敗,都可以執行重試機制的(有些MQ可以自定義重試次數)。

如何避免消息被重複消費造成的問題?

  • 保證消費者調用業務的服務介面的冪等性

  • 通過消費日誌或者類似狀態表來記錄消費狀態,便於判斷(建議在業務上自行實現,而不依賴MQ產品提供該特性)

總結:這種方式比較常見,性能和吞吐量是優於使用關係型資料庫消息表的方案。如果MQ自身和業務都具有高可用性,理論上是可以滿足大部分的業務場景的。不過在沒有充分測試的情況下,不建議在交易業務中直接使用。

MQ(事務消息)

舉個例子,Bob向Smith轉賬,那我們到底是先發送消息,還是先執行扣款操作?

好像都可能會出問題。如果先發消息,扣款操作失敗,那麼Smith的賬戶裡面會多出一筆錢。反過來,如果先執行扣款操作,后發送消息,那有可能扣款成功了但是消息沒發出去,Smith收不到錢。除了上面介紹的通過異常捕獲和回滾的方式外,還有沒有其他的思路呢?

下面以阿里巴巴的RocketMQ中間件為例,分析下其設計和實現思路。

RocketMQ第一階段發送Prepared消息時,會拿到消息的地址,第二階段執行本地事物,第三階段通過第一階段拿到的地址去訪問消息,並修改狀態。細心的讀者可能又發現問題了,如果確認消息發送失敗了怎麼辦?RocketMQ會定期掃描消息集群中的事物消息,這時候發現了Prepared消息,它會向消息發送者確認,Bob的錢到底是減了還是沒減呢?如果減了是回滾還是繼續發送確認消息呢?RocketMQ會根據發送端設置的策略來決定是回滾還是繼續發送確認消息。這樣就保證了消息發送與本地事務同時成功或同時失敗。如下圖:

總結:據筆者的了解,各大知名的電商平台和互聯網公司,幾乎都是採用類似的設計思路來實現「最終一致性」的。這種方式適合的業務場景廣泛,而且比較可靠。不過這種方式技術實現的難度比較大。目前主流的開源MQ(ActiveMQ、RabbitMQ、Kafka)均未實現對事務消息的支持,所以需二次開發或者新造輪子。比較遺憾的是,RocketMQ事務消息部分的代碼也並未開源,需要自己去實現。

其他補償方式

做過支付寶交易介面的同學都知道,我們一般會在支付寶的回調頁面和介面里,解密參數,然後調用系統中更新交易狀態相關的服務,將訂單更新為付款成功。同時,只有當我們回調頁面中輸出了success字樣或者標識業務處理成功相應狀態碼時,支付寶才會停止回調請求。否則,支付寶會每間隔一段時間后,再向客戶方發起回調請求,直到輸出成功標識為止。

其實這就是一個很典型的補償例子,跟一些MQ重試補償機制很類似。

一般成熟的系統中,對於級別較高的服務和介面,整體的可用性通常都會很高。如果有些業務由於瞬時的網路故障或調用超時等問題,那麼這種重試機制其實是非常有效的。

當然,考慮個比較極端的場景,假如系統自身有bug或者程序邏輯有問題,那麼重試1W次那也是無濟於事的。那豈不是就發生了「明明已經付款,卻顯示未付款不發貨」類似的悲劇?

其實為了交易系統更可靠,我們一般會在類似交易這種高級別的服務代碼中,加入詳細日誌記錄的,一旦系統內部引發類似致命異常,會有郵件通知。同時,後台會有定時任務掃描和分析此類日誌,檢查出這種特殊的情況,會嘗試通過程序來補償並郵件通知相關人員。

在某些特殊的情況下,還會有「人工補償」的,這也是最後一道屏障。

寫在最後

上訴的幾種方案中,筆者也大致總結了其設計思路、優勢、劣勢等,相信讀者已經有了一定的理解。其實分散式系統的事務一致性本身是一個技術難題,目前沒有一種很簡單很完美的方案能夠應對所有場景。具體還是要使用者根據不同的業務場景去抉擇。

丁浪,現就職於某垂直電商平台,擔任技術架構師。關注高併發、高可用的架構設計,對系統服務化、分庫分表、性能調優等方面有深入研究和豐富實踐經驗。熱衷於技術研究和分享。

熱門推薦

本文由 一點資訊 提供 原文連結

一點資訊
寫了5860316篇文章,獲得23303次喜歡
留言回覆
回覆
精彩推薦