兩階段提交(2PC)
?????????XA是X/Open CAE Specification (Distributed Transaction Processing)模型中定義的TM(Transaction Manager)與RM(Resource Manager)之間進行通信的接口。
?? ?????在XA規(guī)范中,數(shù)據(jù)庫充當RM角色,應用需要充當TM的角色,即生成全局的txId,調(diào)用XAResource接口,把多個本地事務協(xié)調(diào)為全局統(tǒng)一的分布式事務。
????????二階段提交是XA的標準實現(xiàn)。它將分布式事務的提交拆分為2個階段:prepare和commit/rollback。
????????2PC模型中,在prepare階段需要等待所有參與子事務的反饋,因此可能造成數(shù)據(jù)庫資源鎖定時間過長,不適合并發(fā)高以及子事務生命周長較長的業(yè)務場景。兩階段提交這種解決方案屬于犧牲了一部分可用性來換取的一致性。
補償事務(TCC)
TCC 其實就是采用的補償機制,其核心思想是:針對每個操作,都要注冊一個與其對應的確認和補償(撤銷)操作。TCC模型是把鎖的粒度完全交給業(yè)務處理。它分為三個階段:
Try 階段主要是對業(yè)務系統(tǒng)做檢測及資源預留
Confirm 階段主要是對業(yè)務系統(tǒng)做確認提交,Try階段執(zhí)行成功并開始執(zhí)行 Confirm階段時,默認 Confirm階段是不會出錯的。即:只要Try成功,Confirm一定成功。
Cancel 階段主要是在業(yè)務執(zhí)行錯誤,需要回滾的狀態(tài)下執(zhí)行的業(yè)務取消,預留資源釋放。
匯款服務和收款服務分別需要實現(xiàn),Try-Confirm-Cancel接口,并在業(yè)務初始化階段將其注入到TCC事務管理器中。、
由此可以看出,TCC模型對業(yè)務的侵入強,改造的難度大。
本地消息表(異步確保)
本地消息表這種實現(xiàn)方式應該是業(yè)界使用最多的,其核心思想是將分布式事務拆分成本地事務進行處理,這種思路是來源于ebay。我們可以從下面的流程圖中看出其中的一些細節(jié):
基本思路就是:
????????消息生產(chǎn)方,需要額外建一個消息表,并記錄消息發(fā)送狀態(tài)。消息表和業(yè)務數(shù)據(jù)要在一個事務里提交,也就是說他們要在一個數(shù)據(jù)庫里面。然后消息會經(jīng)過MQ發(fā)送到消息的消費方。如果消息發(fā)送失敗,會進行重試發(fā)送。
????????消息消費方,需要處理這個消息,并完成自己的業(yè)務邏輯。此時如果本地事務處理成功,表明已經(jīng)處理成功了,如果處理失敗,那么就會重試執(zhí)行。如果是業(yè)務上面的失敗,可以給生產(chǎn)方發(fā)送一個業(yè)務補償消息,通知生產(chǎn)方進行回滾等操作。
????????生產(chǎn)方和消費方定時掃描本地消息表,把還沒處理完成的消息或者失敗的消息再發(fā)送一遍。如果有靠譜的自動對賬補賬邏輯,這種方案還是非常實用的。
盡最大努力通知
? ??????最大努力通知方案主要也是借助MQ消息系統(tǒng)來進行事務控制,這一點與可靠消息最終一致方案一樣。看來MQ中間件確實在一個分布式系統(tǒng)架構中,扮演者重要的角色。最大努力通知方案是比較簡單的分布式事務方案,它本質上就是通過定期校對,實現(xiàn)數(shù)據(jù)一致性。
最大努力通知方案的實現(xiàn)
業(yè)務活動的主動方,在完成業(yè)務處理之后,向業(yè)務活動的被動方發(fā)送消息,允許消息丟失。
主動方可以設置時間階梯型通知規(guī)則,在通知失敗后按規(guī)則重復通知,直到通知N次后不再通知。
主動方提供校對查詢接口給被動方按需校對查詢,用于恢復丟失的業(yè)務消息。
業(yè)務活動的被動方如果正常接收了數(shù)據(jù),就正常返回響應,并結束事務。
如果被動方?jīng)]有正常接收,根據(jù)定時策略,向業(yè)務活動主動方查詢,恢復丟失的業(yè)務消息
最大努力通知方案的特點
1、用到的服務模式:可查詢操作、冪等操作。
2、被動方的處理結果不影響主動方的處理結果;
3、適用于對業(yè)務最終一致性的時間敏感度低的系統(tǒng);
4、適合跨企業(yè)的系統(tǒng)間的操作,或者企業(yè)內(nèi)部比較獨立的系統(tǒng)間的操作,比如銀行通知、商戶通知等;
案例:
eBay 本地消息表
本地消息表這種實現(xiàn)方式的思路,其實是源于ebay,后來通過支付寶等公司的布道,在業(yè)內(nèi)廣泛使用。其基本的設計思想是將遠程分布式事務拆分成一系列的本地事務。如果不考慮性能及設計優(yōu)雅,借助關系型數(shù)據(jù)庫中的表即可實現(xiàn)。
舉個經(jīng)典的跨行轉賬的例子來描述。第一步,扣款1W,通過本地事務保證了憑證消息插入到消息表中。第二步,通知對方銀行賬戶上加1W了。那問題來了,如何通知到對方呢?
通常采用兩種方式:
采用時效性高的MQ,由對方訂閱消息并監(jiān)聽,有消息時自動觸發(fā)事件
采用定時輪詢掃描的方式,去檢查消息表的數(shù)據(jù)。
類似使用本地消息表+消息通知的還有去哪兒,蘑菇街
各種第三方支付回調(diào)
最大努力通知型。如支付寶、微信的支付回調(diào)接口方式,不斷回調(diào)直至成功,或直至調(diào)用次數(shù)衰減至失敗狀態(tài)。
我們可以怎么來做
2PC/3PC需要資源管理器(mysql, redis)支持XA協(xié)議,且整個事務的執(zhí)行期間需要鎖住事務資源,會降低性能。故先排除。
TCC的模式,需要事務接口提供try,confirm,cancel三個接口,提高了編程的復雜性。需要依賴于業(yè)務方來配合提供這樣的接口。推行難度大,暫時排除。
最大努力通知型,應用于異構或者服務平臺當中
可以看到ebay的經(jīng)典模式中,分布式的事務,是通過本地事務+可靠消息,來達到事務的最終一致性的。但是出現(xiàn)了事務消息,就把本地事務的工作給涵蓋在事務消息當中了。所以,接下來要基于事務消息來套我們的應用場景,看起是否滿足我們對分布式事務產(chǎn)品的要求。