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

08-15

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

3 人贊了文章

開篇

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

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

分散式系統的特性

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

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

一、兩階段提交（2PC）

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

第一階段，張老師作為「協調者」，給小強和小明（參與者、節點）發微信，組織他們倆明天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、Automikos等來實現，兩者均支持spring事務整合。

而在Windows .NET平台中，則可以藉助http://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層一個本地方法中。
當用戶請求登錄介面時，先執行加積分操作，加分成功後再執行登錄操作
如果登錄成功，那當然最好了，積分也加成功了。如果登錄失敗，則調用加積分對應的回滾介面（執行減積分的操作）。

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

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

二、補償事務（TCC）

TCC 其實就是採用的補償機制，其核心思想是：針對每個操作，都要註冊一個與其對應的確認和補償（撤銷）操作。它分為三個階段：

Try 階段主要是對業務系統做檢測及資源預留
Confirm 階段主要是對業務系統做確認提交，Try階段執行成功並開始執行 Confirm階段時，默認 Confirm階段是不會出錯的。即：只要Try成功，Confirm一定成功。
Cancel 階段主要是在業務執行錯誤，需要回滾的狀態下執行的業務取消，預留資源釋放。

舉個例子，假入 Bob 要向 Smith 轉賬，思路大概是：

我們有一個本地方法，裡面依次調用

1、首先在 Try 階段，要先調用遠程介面把 Smith 和 Bob 的錢給凍結起來。

2、在 Confirm 階段，執行遠程調用的轉賬的操作，轉賬成功進行解凍。

3、如果第2步執行成功，那麼轉賬成功，如果第二步執行失敗，則調用遠程凍結介面對應的解凍方法 (Cancel)。

優點： 跟2PC比起來，實現以及流程相對簡單了一些，但數據的一致性比2PC也要差一些

缺點： 缺點還是比較明顯的，在2,3步中都有可能失敗。TCC屬於應用層的一種補償方式，所以需要程序員在實現的時候多寫很多補償的代碼，在一些場景中，一些業務流程可能用TCC不太好定義及處理。

三、本地消息表

這種實現方式的思路，其實是源於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事務消息部分的代碼也並未開源，需要自己去實現。

六、Sagas 事務模型

Saga事務模型又叫做長時間運行的事務（Long-running-transaction）, 它是由普林斯頓大學的H.Garcia-Molina等人提出，它描述的是另外一種在沒有兩階段提交的的情況下解決分散式系統中複雜的業務事務問題。你可以在這裡看到 Sagas 相關論文。

我們這裡說的是一種基於 Sagas 機制的工作流事務模型，這個模型的相關理論目前來說還是比較新的，以至於百度上幾乎沒有什麼相關資料。

該模型其核心思想就是拆分分散式系統中的長事務為多個短事務，或者叫多個本地事務，然後由 Sagas 工作流引擎負責協調，如果整個流程正常結束，那麼就算是業務成功完成，如果在這過程中實現失敗，那麼Sagas工作流引擎就會以相反的順序調用補償操作，重新進行業務回滾。

比如我們一次關於購買旅遊套餐業務操作涉及到三個操作，他們分別是預定車輛，預定賓館，預定機票，他們分別屬於三個不同的遠程介面。可能從我們程序的角度來說他們不屬於一個事務，但是從業務角度來說是屬於同一個事務的。

他們的執行順序如上圖所示，所以當發生失敗時，會依次進行取消的補償操作。

因為長事務被拆分了很多個業務流，所以 Sagas 事務模型最重要的一個部件就是工作流或者你也可以叫流程管理器（Process Manager），工作流引擎和Process Manager雖然不是同一個東西，但是在這裡，他們的職責是相同的。在選擇工作流引擎之後，最終的代碼也許看起來是這樣的

SagaBuilder saga = SagaBuilder.newSaga("trip") .activity("Reserve car", ReserveCarAdapter.class) .compensationActivity("Cancel car", CancelCarAdapter.class) .activity("Book hotel", BookHotelAdapter.class) .compensationActivity("Cancel hotel", CancelHotelAdapter.class) .activity("Book flight", BookFlightAdapter.class) .compensationActivity("Cancel flight", CancelFlightAdapter.class) .end() .triggerCompensationOnAnyError();camunda.getRepositoryService().createDeployment() .addModelInstance(saga.getModel()) .deploy();

這裡有一個 C# 相關示例，有興趣的同學可以看一下。

優缺點這裡我們就不說了，因為這個理論比較新，目前市面上還沒有什麼解決方案，即使是 Java 領域，我也沒有搜索的太多有用的信息。

其他補償方式

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

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

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

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

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

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

小結

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

----------------------------------------------------------------------------------------

最終一致性的常用做法

1、單資料庫事務

如果應用系統是單一的資料庫，那麼這個很好保證，利用資料庫的事務特性來滿足事務的一致性，這時候的一致性是強一致性的。對於java應用系統來講，很少直接通過事務的start和commit以及rollback來硬編碼，大多通過spring的事務模板或者聲明式事務來保證；

2、多資料庫事務

針對多資料庫事務可以根據二階段提交協議，採用spring 3.0 + Atomikos + JTA進行支持；

3、基於事務型消息隊列的最終一致性

藉助消息隊列，在處理業務邏輯的地方發送消息，業務邏輯處理成功後，提交消息，確保消息是發送成功的，之後消息隊列投遞來進行處理，如果成功，則結束，如果沒有成功，則重試，直到成功，不過僅僅適用業務邏輯中，第一階段成功，第二階段必須成功的場景。對應上圖中的C流程。

4、基於消息隊列+定時補償機制的最終一致性

前面部分和上面基於事務型消息的隊列，不同的是，第二階段重試的地方，不再是消息中間件自身的重試邏輯了，而是單獨的補償任務機制。其實在大多數的邏輯中，第二階段失敗的概率比較小，所以單獨獨立補償任務表出來，可以更加清晰，能夠比較明確的直到當前多少任務是失敗的。對應上圖的E流程。

5、非同步回調機制的引入

A應用調用B，在同步調用的返回結果中，B返回成功給到A，一般情況下，這時候就結束了，其實在99.99%的情況是沒問題的，但是有時候為了確保100%，記住最起碼在系統設計中100%，這時候B系統再回調A一下，告訴A，你調用我的邏輯，確實成功了。其實這個邏輯，非常類似TCP協議中的三次握手。上圖中的B流程。

6、類似double check機制的確認機制

還是上圖中非同步回調的過程，A在同步調用B，B返回成功了。這次調用結束了，但是A為了確保，在過一段時間，這個時間可以是幾秒，也可以是每天定時處理，再調用B一次，查詢一下之前的那次調用是否成功。例如A調用B更新訂單狀態，這時候成功了，延遲幾秒後，A查詢B，確認一下狀態是否是自己剛剛期望的。