兩階段提交（2PC）

?????????XA是X/Open CAE Specification (Distributed Transaction Processing)模型中定義的TM（Transaction Manager）與RM（Resource Manager）之間進(jìn)行通信的接口圾另。

?? ?????在XA規(guī)范中，數(shù)據(jù)庫充當(dāng)RM角色戚宦，應(yīng)用需要充當(dāng)TM的角色，即生成全局的txId蕾额，調(diào)用XAResource接口野建，把多個本地事務(wù)協(xié)調(diào)為全局統(tǒng)一的分布式事務(wù)。

????????二階段提交是XA的標(biāo)準(zhǔn)實(shí)現(xiàn)确买。它將分布式事務(wù)的提交拆分為2個階段：prepare和commit/rollback斤讥。

????????2PC模型中，在prepare階段需要等待所有參與子事務(wù)的反饋湾趾，因此可能造成數(shù)據(jù)庫資源鎖定時間過長芭商，不適合并發(fā)高以及子事務(wù)生命周長較長的業(yè)務(wù)場景。兩階段提交這種解決方案屬于犧牲了一部分可用性來換取的一致性搀缠。

補(bǔ)償事務(wù)（TCC）

TCC 其實(shí)就是采用的補(bǔ)償機(jī)制铛楣，其核心思想是：針對每個操作，都要注冊一個與其對應(yīng)的確認(rèn)和補(bǔ)償（撤銷）操作艺普。TCC模型是把鎖的粒度完全交給業(yè)務(wù)處理簸州。它分為三個階段：

Try 階段主要是對業(yè)務(wù)系統(tǒng)做檢測及資源預(yù)留

Confirm 階段主要是對業(yè)務(wù)系統(tǒng)做確認(rèn)提交，Try階段執(zhí)行成功并開始執(zhí)行 Confirm階段時衷敌，默認(rèn) Confirm階段是不會出錯的勿侯。即：只要Try成功，Confirm一定成功缴罗。

Cancel 階段主要是在業(yè)務(wù)執(zhí)行錯誤助琐，需要回滾的狀態(tài)下執(zhí)行的業(yè)務(wù)取消，預(yù)留資源釋放面氓。

匯款服務(wù)和收款服務(wù)分別需要實(shí)現(xiàn)兵钮，Try-Confirm-Cancel接口，并在業(yè)務(wù)初始化階段將其注入到TCC事務(wù)管理器中舌界。掘譬、

由此可以看出，TCC模型對業(yè)務(wù)的侵入強(qiáng)呻拌，改造的難度大葱轩。

本地消息表（異步確保）

本地消息表這種實(shí)現(xiàn)方式應(yīng)該是業(yè)界使用最多的，其核心思想是將分布式事務(wù)拆分成本地事務(wù)進(jìn)行處理，這種思路是來源于ebay靴拱。我們可以從下面的流程圖中看出其中的一些細(xì)節(jié)：

基本思路就是：

????????消息生產(chǎn)方垃喊，需要額外建一個消息表，并記錄消息發(fā)送狀態(tài)袜炕。消息表和業(yè)務(wù)數(shù)據(jù)要在一個事務(wù)里提交本谜，也就是說他們要在一個數(shù)據(jù)庫里面。然后消息會經(jīng)過MQ發(fā)送到消息的消費(fèi)方偎窘。如果消息發(fā)送失敗乌助，會進(jìn)行重試發(fā)送。

????????消息消費(fèi)方陌知，需要處理這個消息他托，并完成自己的業(yè)務(wù)邏輯。此時如果本地事務(wù)處理成功纵诞，表明已經(jīng)處理成功了上祈，如果處理失敗，那么就會重試執(zhí)行浙芙。如果是業(yè)務(wù)上面的失敗登刺，可以給生產(chǎn)方發(fā)送一個業(yè)務(wù)補(bǔ)償消息，通知生產(chǎn)方進(jìn)行回滾等操作嗡呼。

????????生產(chǎn)方和消費(fèi)方定時掃描本地消息表纸俭，把還沒處理完成的消息或者失敗的消息再發(fā)送一遍。如果有靠譜的自動對賬補(bǔ)賬邏輯南窗，這種方案還是非常實(shí)用的揍很。

盡最大努力通知

? ??????最大努力通知方案主要也是借助MQ消息系統(tǒng)來進(jìn)行事務(wù)控制，這一點(diǎn)與可靠消息最終一致方案一樣万伤≈匣冢看來MQ中間件確實(shí)在一個分布式系統(tǒng)架構(gòu)中，扮演者重要的角色敌买。最大努力通知方案是比較簡單的分布式事務(wù)方案简珠，它本質(zhì)上就是通過定期校對，實(shí)現(xiàn)數(shù)據(jù)一致性虹钮。

最大努力通知方案的實(shí)現(xiàn)

業(yè)務(wù)活動的主動方聋庵，在完成業(yè)務(wù)處理之后，向業(yè)務(wù)活動的被動方發(fā)送消息芙粱，允許消息丟失祭玉。

主動方可以設(shè)置時間階梯型通知規(guī)則，在通知失敗后按規(guī)則重復(fù)通知春畔，直到通知N次后不再通知脱货。

主動方提供校對查詢接口給被動方按需校對查詢岛都，用于恢復(fù)丟失的業(yè)務(wù)消息。

業(yè)務(wù)活動的被動方如果正常接收了數(shù)據(jù)蹭劈，就正常返回響應(yīng)疗绣，并結(jié)束事務(wù)线召。

如果被動方?jīng)]有正常接收铺韧，根據(jù)定時策略，向業(yè)務(wù)活動主動方查詢缓淹，恢復(fù)丟失的業(yè)務(wù)消息

最大努力通知方案的特點(diǎn)

1哈打、用到的服務(wù)模式：可查詢操作、冪等操作讯壶。

2料仗、被動方的處理結(jié)果不影響主動方的處理結(jié)果；

3伏蚊、適用于對業(yè)務(wù)最終一致性的時間敏感度低的系統(tǒng)立轧；

4、適合跨企業(yè)的系統(tǒng)間的操作躏吊，或者企業(yè)內(nèi)部比較獨(dú)立的系統(tǒng)間的操作氛改，比如銀行通知、商戶通知等比伏；

案例：

eBay 本地消息表

本地消息表這種實(shí)現(xiàn)方式的思路胜卤，其實(shí)是源于ebay，后來通過支付寶等公司的布道赁项，在業(yè)內(nèi)廣泛使用葛躏。其基本的設(shè)計思想是將遠(yuǎn)程分布式事務(wù)拆分成一系列的本地事務(wù)。如果不考慮性能及設(shè)計優(yōu)雅悠菜，借助關(guān)系型數(shù)據(jù)庫中的表即可實(shí)現(xiàn)舰攒。

舉個經(jīng)典的跨行轉(zhuǎn)賬的例子來描述。第一步悔醋，扣款1W摩窃，通過本地事務(wù)保證了憑證消息插入到消息表中。第二步篙顺，通知對方銀行賬戶上加1W了偶芍。那問題來了，如何通知到對方呢德玫？

通常采用兩種方式：

采用時效性高的MQ匪蟀，由對方訂閱消息并監(jiān)聽，有消息時自動觸發(fā)事件

采用定時輪詢掃描的方式宰僧，去檢查消息表的數(shù)據(jù)材彪。

類似使用本地消息表+消息通知的還有去哪兒，蘑菇街

各種第三方支付回調(diào)

最大努力通知型。如支付寶段化、微信的支付回調(diào)接口方式嘁捷，不斷回調(diào)直至成功，或直至調(diào)用次數(shù)衰減至失敗狀態(tài)显熏。

我們可以怎么來做

2PC/3PC需要資源管理器(mysql, redis)支持XA協(xié)議雄嚣，且整個事務(wù)的執(zhí)行期間需要鎖住事務(wù)資源，會降低性能喘蟆。故先排除缓升。

TCC的模式，需要事務(wù)接口提供try,confirm,cancel三個接口蕴轨，提高了編程的復(fù)雜性港谊。需要依賴于業(yè)務(wù)方來配合提供這樣的接口。推行難度大橙弱，暫時排除歧寺。

最大努力通知型，應(yīng)用于異構(gòu)或者服務(wù)平臺當(dāng)中

可以看到ebay的經(jīng)典模式中棘脐，分布式的事務(wù)斜筐，是通過本地事務(wù)+可靠消息，來達(dá)到事務(wù)的最終一致性的荆残。但是出現(xiàn)了事務(wù)消息奴艾，就把本地事務(wù)的工作給涵蓋在事務(wù)消息當(dāng)中了。所以内斯，接下來要基于事務(wù)消息來套我們的應(yīng)用場景蕴潦，看起是否滿足我們對分布式事務(wù)產(chǎn)品的要求。