支付寶分布式事務(wù)設(shè)計(jì)草案

1、支付寶分布式事務(wù)架構(gòu)設(shè)計(jì)草案1 背景介紹為了應(yīng)對(duì)快速變化的市場(chǎng)需求、持續(xù)增長(zhǎng)的業(yè)務(wù)量，支付寶系統(tǒng)需要基于SOA 進(jìn)行構(gòu)建與改造， 以應(yīng)對(duì)系統(tǒng)規(guī)模和復(fù)雜性的挑戰(zhàn)， 更好地進(jìn)行企業(yè) 內(nèi)與企業(yè)間的協(xié)作?；?SOA 圖景，整個(gè)支付寶系統(tǒng)會(huì)拆分成一系列獨(dú)立開(kāi)發(fā)、自包含、自 主運(yùn)行的業(yè)務(wù)服務(wù)，并將這些服務(wù)通過(guò)各種機(jī)制靈活地組裝成最終用戶所 需要的產(chǎn)品與解決方案。支付寶系統(tǒng)將會(huì)有類似下圖所示的 SOA 模型：在SOA的系統(tǒng)架構(gòu)下，一次業(yè)務(wù)請(qǐng)求將會(huì)跨越多個(gè)服務(wù)。我們舉一個(gè)使 用紅包+余額進(jìn)行交易付款的例子來(lái)說(shuō)明。在多個(gè)服務(wù)協(xié)同完成一次業(yè)務(wù)時(shí)，由于業(yè)務(wù)約束（如紅包不符合使用條件、賬戶余額不足等）、系統(tǒng)故障（如

2、網(wǎng)絡(luò)或系統(tǒng)超時(shí)或中斷、數(shù)據(jù)庫(kù)約束不 滿足等），都可能造成服務(wù)處理過(guò)程在任何一步無(wú)法繼續(xù)，使數(shù)據(jù)處于不 一致的狀態(tài)，產(chǎn)生嚴(yán)重的業(yè)務(wù)后果。傳統(tǒng)的基于數(shù)據(jù)庫(kù)本地事務(wù)的解決方案只能保障單個(gè)服務(wù)的一次處理具備原子性、隔離性、一致性與持久性，但無(wú)法保障多個(gè)分布服務(wù)間處理的 一致性。因此，我們必須建立一套分布式服務(wù)處理之間的協(xié)調(diào)機(jī)制，保障 分布式服務(wù)處理的原子性、隔離性、一致性與持久性。2基本原理2.1兩階段提交協(xié)議（2PC）傳統(tǒng)的分布式事務(wù)處理是基于兩階段提交協(xié)議的。兩階段提交協(xié)議的原理如下圖所示:成功的兩階段提交（2PC）示例分布式事務(wù)協(xié)調(diào)者1.準(zhǔn)備2.已準(zhǔn)備5.放棄6.完成3.準(zhǔn)備4.已放棄7放棄8.

3、完成分布式事務(wù)參與者分布式事務(wù)參與者失敗的兩階段提交(2PC)示例從上圖可見(jiàn)，兩階段提交協(xié)議的關(guān)鍵在于“準(zhǔn)備”操作。分布式事務(wù)協(xié)調(diào) 者在第一階段通過(guò)對(duì)所有的分布式事務(wù)參與者請(qǐng)求“準(zhǔn)備”操作，達(dá)成關(guān) 于分布式事務(wù)一致性的共識(shí)。分布式事務(wù)參與者在準(zhǔn)備階段必須完成所有 的約束檢查、并且確保后續(xù)提交或放棄時(shí)所需要的數(shù)據(jù)已持久化。在第二 隊(duì)段，分布式事務(wù)協(xié)調(diào)者根據(jù)之前達(dá)到的提交或放棄的共識(shí)，請(qǐng)求所有的 分布式事務(wù)參與者完成相應(yīng)的操作。2.2最末參與者優(yōu)化(LPO)兩階段提交協(xié)議要求分布式事務(wù)參與者實(shí)現(xiàn)一個(gè)特別的“準(zhǔn)備”操作，無(wú) 論在資源管理器(如數(shù)據(jù)庫(kù))還是在業(yè)務(wù)服務(wù)中實(shí)現(xiàn)該操作都存在效率與 復(fù)雜性的挑

4、戰(zhàn)。因此，兩階段提交協(xié)議有一個(gè)重要的優(yōu)化，稱為“最末參 與者優(yōu)化” (Last Participant Optimization)，允許兩階段提交協(xié)議中有一個(gè)參與者不實(shí)現(xiàn)“準(zhǔn)備”操作(稱為單階段參與者)。最末參與者優(yōu)化的原理如下圖所示：分布式事務(wù)協(xié)調(diào)者1.準(zhǔn)備2.已準(zhǔn)備5.提交6.完成3.提交4.完成單階段參與者最末參與者優(yōu)化(LPO)示例兩階段參與者最末參與者優(yōu)化(LPO)示例成功場(chǎng)景失敗場(chǎng)景從上圖可見(jiàn)，LPO中，單階段參與者不需要實(shí)現(xiàn)準(zhǔn)備操作，只需要提供 標(biāo)準(zhǔn)的提交操作即可。分布式事務(wù)協(xié)調(diào)者必須等其余兩階段參與者都準(zhǔn)備 好之后，再請(qǐng)求單階段參與者提交，單階段參與者的提交結(jié)果將決定整個(gè) 分布

5、式事務(wù)的結(jié)果。本質(zhì)上，LPO是將最后一個(gè)參與者的準(zhǔn)備操作與提交 /放棄操作合并成一個(gè)提交操作。最末參與者優(yōu)化方案使得我們能夠利用支付寶業(yè)務(wù)的特點(diǎn)，盡量簡(jiǎn)化分布 式事務(wù)的實(shí)現(xiàn)。2.3X/Open 模型X/Open組織為基于兩階段協(xié)議的分布式事務(wù)處理系統(tǒng)提出了標(biāo)準(zhǔn)的系統(tǒng)參考模型（X/Open事務(wù)模型）、以與不同組件間與事務(wù)協(xié)調(diào)相關(guān)的接口,使不同廠商的產(chǎn)品能夠互操作。X/Ope n事務(wù)模型如下圖所示：從上圖可以看出，X/Open模型定義了兩個(gè)標(biāo)準(zhǔn)接口： TX接口用于應(yīng)用程序向事務(wù)管理器發(fā)起事務(wù)、提交事務(wù)和回滾事務(wù)（即確定事務(wù)的邊界和結(jié) 果）；XA接口用于事務(wù)管理器將資源管理器（如數(shù)據(jù)庫(kù)、消息隊(duì)列等）

6、加 入事務(wù)、并控制兩階段提交。事務(wù)管理器一般由專門(mén)的中間件提供、或者在應(yīng)用服務(wù)器中作為一個(gè)重要 的組件提供。資源管理器如數(shù)據(jù)庫(kù)、消息隊(duì)列一般也會(huì)提供 XA 支持。通 過(guò)使用符合 X/Open 標(biāo)準(zhǔn)的分布式事務(wù)處理， 能夠簡(jiǎn)化分布式事務(wù)類應(yīng)用 的開(kāi)發(fā)。但在現(xiàn)實(shí)中，事務(wù)管理器與資源管理器對(duì) TX/XA 協(xié)議的實(shí)現(xiàn)上存在效率、 可靠性與伸縮性上的風(fēng)險(xiǎn)；在兩階段提交協(xié)議執(zhí)行過(guò)程中的異常恢復(fù)起來(lái) 也很困難；而且在 SOA 體系下當(dāng)事務(wù)需要跨越多個(gè)服務(wù)（而不是多個(gè)資 源管理器）時(shí)，事務(wù)的協(xié)調(diào)與恢復(fù)會(huì)變得非常復(fù)雜。在標(biāo)準(zhǔn)分布式事務(wù)管理框架不能滿足需要的情況下，我們需要根據(jù)支付寶 業(yè)務(wù)與系統(tǒng)的特點(diǎn)，設(shè)計(jì)并實(shí)現(xiàn)

7、自己的分布式事務(wù)處理機(jī)制。下一節(jié)介紹 支付寶分布式事務(wù)處理的基礎(chǔ)模型。3 基礎(chǔ)模型3.1典型業(yè)務(wù)處理模式支付寶的主體業(yè)務(wù)基本都會(huì)在一次業(yè)務(wù)處理中進(jìn)行一次或多次賬務(wù)處理。 典型的業(yè)務(wù)處理模式如下圖所示：業(yè)務(wù)朋務(wù)1：業(yè)務(wù)絢束檢査2：業(yè)務(wù)數(shù)據(jù)處理t3:賬務(wù)處理4約東檢査<1?： -iL-'r.6:根據(jù)SK務(wù)處理結(jié)黒進(jìn)場(chǎng)處理址務(wù)數(shù)據(jù)在黃址券處咒屮.町施 若次調(diào)月WK務(wù)業(yè):性并楸樨 鮭處理的第卑決定是音業(yè)務(wù) 處理展否成功這種模式可以概括如下：支付寶的主體業(yè)務(wù)服務(wù)在執(zhí)行過(guò)程中一般都會(huì)涉與到一次或者多次的賬務(wù)處理。業(yè)務(wù)服務(wù)與賬務(wù)服務(wù)對(duì)業(yè)務(wù)處理的最終結(jié)果有同等的決定權(quán)，兩者都能夠使業(yè)務(wù)處理失敗。

8、當(dāng)一次業(yè)務(wù)處理中涉與到超過(guò)兩個(gè)參與者時(shí)，附加的參與者一般對(duì)業(yè)務(wù)處理的最終結(jié)果沒(méi)有決定權(quán)，但它們會(huì)根據(jù)業(yè)務(wù)處理的最終結(jié)果完成自 己的處理。例如，很多業(yè)務(wù)在完成之后都涉與到收費(fèi)的處理，但一般收費(fèi)不成功不會(huì)影響業(yè)務(wù)處理本身的結(jié)果。根據(jù)兩參與者的特點(diǎn)，以與賬務(wù)服務(wù)的中心地位，我們可以根據(jù)“兩階段提交協(xié)議”以與“最末參與者優(yōu)化”原理，設(shè)計(jì)支付寶分布式事務(wù)處理的 基礎(chǔ)模型3.2基礎(chǔ)模型這一基礎(chǔ)模型如下圖所示:業(yè)務(wù)處理域查門(mén)分支事務(wù)(準(zhǔn)備事務(wù)管理域本地事務(wù)域本地事務(wù)域賬務(wù)核心(3)業(yè)務(wù)服務(wù)管理器(5)賬務(wù)確認(rèn)廠LLL、主事務(wù)查詢 管理器T1T (4) 勾對(duì)開(kāi)始 提交-1 'x 回滾X，J確認(rèn) 賬務(wù)操

9、作 -VJ賬務(wù)前置在上圖中，各個(gè)主要組件的職責(zé)如下：(1)業(yè)務(wù)服務(wù)業(yè)務(wù)服務(wù)負(fù)責(zé)具體業(yè)務(wù)處理，如交易服務(wù)、紅包服務(wù)等等。賬務(wù)前置賬務(wù)前置負(fù)責(zé)接收、檢查并緩沖從業(yè)務(wù)服務(wù)發(fā)起的賬務(wù)請(qǐng)求(3) 賬務(wù)核心 負(fù)責(zé)記賬并更新分戶余額。(4) 主事務(wù)管理器 與業(yè)務(wù)服務(wù)位于同一個(gè)本地事務(wù)域，負(fù)責(zé)主事務(wù)的啟動(dòng)、提交與回滾。(5) 分支事務(wù)管理器 與賬務(wù)服務(wù)位于同一個(gè)本地事務(wù)域，負(fù)責(zé)分支事務(wù)的準(zhǔn)備，確認(rèn)與取消。(6) 事務(wù)恢復(fù) daemon 定時(shí)運(yùn)行，負(fù)責(zé)恢復(fù)處于已準(zhǔn)備狀態(tài)，但在指定時(shí)間閾值內(nèi)尚未確認(rèn)或者 取消的事務(wù)。下面我們介紹上述組件如何通過(guò)協(xié)作完成一次包含賬務(wù)的業(yè)務(wù)處理。3.3準(zhǔn)備階段下圖顯示在“準(zhǔn)備”階段各

10、個(gè)組件間的交互過(guò)程。1：評(píng)始主事壽 ；b一一3羋竺燧續(xù)業(yè)務(wù)處理61.業(yè)務(wù)服務(wù)(1)首先向主事務(wù)管理器請(qǐng)求幵始主事務(wù)，此時(shí)，主事務(wù)管理器啟動(dòng)本地事務(wù)，按照一定規(guī)則生成一個(gè)對(duì)本次處理唯一的txld，記錄主事務(wù)日志，并在事務(wù)上下文中記錄 txld，這個(gè)txld在整個(gè)分布式 事務(wù)的生命周期中用于建立主事務(wù)與分支事務(wù)之間的對(duì)應(yīng)關(guān)系，并用于業(yè)務(wù)重復(fù)性檢查。2. 業(yè)務(wù)服務(wù)向賬務(wù)前置發(fā)送賬務(wù)處理請(qǐng)求。主事務(wù)管理器能夠攔截本次請(qǐng)求，并將主事務(wù)ID(txId)附加到賬務(wù)處理請(qǐng)求的上下文中，一起發(fā)送給 賬務(wù)前置。3. 賬務(wù)前置進(jìn)行前置約束檢查。前置約束檢查至少要保證：a.事務(wù)Id有效；b.業(yè)務(wù)不重復(fù)。前置約束檢查前

11、，相關(guān)賬戶必須鎖定(除特定賬 戶外、如中間賬戶等)。4. 賬務(wù)前置調(diào)用賬務(wù)核心進(jìn)行賬務(wù)約束檢查。賬務(wù)約束檢查至少要保證：a.賬戶狀態(tài)正確；b.賬戶資金足夠；c.其它賬務(wù)約束滿足。賬務(wù)約束檢查時(shí)必須考慮到在本事務(wù)中尚未到達(dá)的資金， 因此這是檢查中比較特 殊的地方，需要恰當(dāng)處理。5. 賬務(wù)前置調(diào)用賬務(wù)核心進(jìn)行資金凍結(jié)。 對(duì)于完成本次賬務(wù)處理需要的資 金，需要一種特殊的方式凍結(jié)起來(lái)，但這種凍結(jié)沒(méi)有業(yè)務(wù)含義，因此， 不應(yīng)該記錄資金凍結(jié)日志，只是在 freeze_amount 中增加這筆凍結(jié)資 金，確保賬務(wù)確認(rèn)階段能夠使用這筆資金。 如果本次賬務(wù)處理所需要的 資金尚未到達(dá)，則不需要凍結(jié)。6. 賬務(wù)前置調(diào)

12、用分支事務(wù)管理器記錄分支事務(wù)日志。 分支事務(wù)日志中記錄 了本次賬務(wù)處理的內(nèi)容以與凍結(jié)的金額， 在確認(rèn)階段， 分支事務(wù)管理器 會(huì)根據(jù)分支事務(wù)日志中記錄的內(nèi)容驅(qū)動(dòng)賬務(wù)系統(tǒng)完成預(yù)凍結(jié)金額的解 凍與實(shí)際的賬務(wù)處理。7. 賬務(wù)前置向業(yè)務(wù)服務(wù)返回賬務(wù)處理的結(jié)果。8. 業(yè)務(wù)服務(wù)根據(jù)賬務(wù)處理的結(jié)果繼續(xù)進(jìn)行業(yè)務(wù)處理。在一次業(yè)務(wù)處理過(guò)程上，上述交互過(guò)程允許進(jìn)行發(fā)生多次。但為了控制遠(yuǎn) 程調(diào)用的成本，也可以將賬務(wù)請(qǐng)求打成包合并發(fā)送給賬務(wù)前置。3.4確認(rèn)階段下圖顯示在“確認(rèn)”階段各個(gè)組件的交互過(guò)程。業(yè)升11*11111:煜交事務(wù)'.二誡M甘：扌l(wèi)3：4-:爭(zhēng) 4B：徇咆槍盍a也阿番鼻牡沖衍収1：迥冋瞰務(wù)旳JL誹

13、*I I i iir.請(qǐng)求悵務(wù)赴理：yOr5： 吵可:冷；12.:川 l.'L bk'f1. 業(yè)務(wù)服務(wù)請(qǐng)求主事務(wù)管理器提交事務(wù)。2. 主事務(wù)管理器首先完成本地事務(wù)的提交。3. 主事務(wù)管理器向業(yè)務(wù)系統(tǒng)返回事務(wù)提交的結(jié)果。4. 主事務(wù)管理器向分支事務(wù)管理器確認(rèn)分支事務(wù)結(jié)果。5. 分支事務(wù)管理器順序處理對(duì)應(yīng)于本次分布式事務(wù)的每一條分支事務(wù)日志，對(duì)每一條分支事務(wù)日志，調(diào)用賬務(wù)前置確認(rèn)該次處理。6. 賬務(wù)前置首先請(qǐng)求賬務(wù)核心解凍預(yù)凍結(jié)的資金。7. 賬務(wù)前置請(qǐng)求賬務(wù)核心進(jìn)行賬務(wù)處理。8. 賬務(wù)核心對(duì)本次賬務(wù)處理進(jìn)行約束檢查。對(duì)于特定的檢查（比如賬戶狀態(tài)是否有效等）是否需要做，視業(yè)務(wù)而定。9

14、. 賬務(wù)核心進(jìn)行賬務(wù)處理，包含記錄賬務(wù)日志并更新賬戶余額等。其它正常賬務(wù)處理中需要執(zhí)行的工作也同樣需要做。10. 賬務(wù)核心向賬務(wù)前置返回賬務(wù)處理的結(jié)果。11. 賬務(wù)前置向分支事務(wù)管理器返回賬務(wù)確認(rèn)的結(jié)果，分支事務(wù)管理器提交本地事務(wù)。12. 分支事務(wù)管理器請(qǐng)求主事務(wù)管理器勾對(duì)主事務(wù)。勾對(duì)的方式可以是刪除主事務(wù)記錄，也可以是為主事務(wù)記錄打上標(biāo)志。3.5回滾階段業(yè)字歸務(wù)卞爭(zhēng)務(wù)性師器 ir > :i- '<- |-吐4代山1. 業(yè)務(wù)服務(wù)請(qǐng)求主事務(wù)管理器回滾事務(wù)。2. 主事務(wù)管理器回滾本地事務(wù)。3. 主事務(wù)管理器向業(yè)務(wù)系統(tǒng)返回回滾結(jié)果。4. 主事務(wù)管理器向分支事務(wù)管理器請(qǐng)求取消分支事

15、務(wù)。5. 分支事務(wù)管理器針對(duì)每一條分支事務(wù)明細(xì)，向賬務(wù)前置請(qǐng)求取消賬務(wù)處 理。6. 賬務(wù)前置向賬務(wù)核心請(qǐng)求解凍預(yù)凍結(jié)資金。7. 分支事務(wù)管理器清除分支事務(wù)日志。1: M£tt£爭(zhēng)齊詼復(fù)aa£mon1：爭(zhēng)齊科理器(4)I蘆彥詢處+到期的prepa件狀念的哲咅<主豊一蘭仝勺上(1心小耳.叮彳t犁列胡實(shí)現(xiàn)時(shí)碎*事齊可能尚未提交)辺|別乳芝確認(rèn)弓取悄的韋務(wù)列恚Iloop丿!【冏弁2翌認(rèn)的分圭爭(zhēng)務(wù)!片確認(rèn)分龍界券fau1igp丿!肝育気嬰儀諂的分支爭(zhēng)務(wù)7：取沸分支峯備3.6恢復(fù)階段1. 定時(shí)器定期觸發(fā)事務(wù)恢復(fù) daemon程序，進(jìn)行事務(wù)恢復(fù)。定期的間隔 可以是每分鐘一

16、次。2. 事務(wù)恢復(fù) daemon 程序向分支事務(wù)管理器查詢處于已到期的處于 prepare狀態(tài)的分支事務(wù)。已到期的具體時(shí)間一般是允許的最大事務(wù)長(zhǎng) 度，比如90秒。3. 事務(wù)恢復(fù)daemon 針對(duì)每條到期的處于 prepare狀態(tài)的分支事務(wù)，向 主事務(wù)管理器查詢主事務(wù)狀態(tài)。4. 主事務(wù)管理器向事務(wù)恢復(fù) daemon返回主事務(wù)狀態(tài)。5. 事務(wù)恢復(fù)daemon根據(jù)查詢主事務(wù)狀態(tài)的結(jié)果，得到需要確認(rèn)與取消 的分支事務(wù)列表。 如果主事務(wù)狀態(tài)是已提交， 則表明分支事務(wù)需要提交。 如果主事務(wù)狀態(tài)不存在(即沒(méi)有主事務(wù)日志) ，則表明主事務(wù)已回滾。 這里需要特別注意的是， 如果主事務(wù)執(zhí)行時(shí)間過(guò)長(zhǎng)， 則可能在查詢

17、時(shí)主 事務(wù)還處于執(zhí)行階段， 尚未提交。 通過(guò)限制主事務(wù)長(zhǎng)度， 可以解決這個(gè) 問(wèn)題。需要考慮一下有無(wú)更好更安全的方案。6. 事務(wù)恢復(fù) daemon 針對(duì)每條需要確認(rèn)的分支事務(wù)，請(qǐng)求分支事務(wù)管理 器確認(rèn)事務(wù)。7. 事務(wù)恢復(fù) daemon 針對(duì)每條需要取消的分支事務(wù)，請(qǐng)求分支事務(wù)管理 器取消事務(wù)。3.7預(yù)凍結(jié)款與未達(dá)款計(jì)算在準(zhǔn)備階段，賬務(wù)前置需要計(jì)算出預(yù)凍結(jié)金額，并請(qǐng)求賬務(wù)核心凍結(jié)該部 分金額，確保在確認(rèn)階段相關(guān)的賬務(wù)處理有足夠的金額。在一次分布式事 務(wù)處理中，業(yè)務(wù)服務(wù)可能多次請(qǐng)求賬務(wù)處理，資金可能在多個(gè)賬戶間發(fā)生 轉(zhuǎn)移。由于在準(zhǔn)備階段，賬務(wù)前置只負(fù)責(zé)預(yù)凍結(jié)資金，而不會(huì)進(jìn)行實(shí)際的 資金轉(zhuǎn)移，因此對(duì)于

18、資金轉(zhuǎn)入賬戶，在準(zhǔn)備階段存在“未達(dá)款” (應(yīng)該轉(zhuǎn) 入但實(shí)際未轉(zhuǎn)入的資金) 。在計(jì)算預(yù)凍結(jié)金額時(shí)，必須考慮未達(dá)款。假設(shè)在一次業(yè)務(wù)處理中，有以下三次賬務(wù)處理：(1) A - (100)-> B: 從 A 賬戶轉(zhuǎn) 100 元至 B 賬戶(2) B - (50)-> C: 從 B 賬戶轉(zhuǎn) 50 元至 C 賬戶C -200)-> D: 從C賬戶轉(zhuǎn)200元至D賬戶則預(yù)凍結(jié)款與未達(dá)款的計(jì)算如下表所示：No#ABCD預(yù)凍結(jié)未達(dá)預(yù)凍結(jié)未達(dá)預(yù)凍結(jié)未達(dá)預(yù)凍結(jié)未達(dá)110000100000021000050050003100005015000200從上表可以看出，賬戶前置必須在每一次處理時(shí)計(jì)算并更新本

19、次處理過(guò)程 中所涉與到的各個(gè)賬戶的預(yù)凍結(jié)款與未達(dá)款。本次處理中涉與到的所有賬 戶的預(yù)凍結(jié)款之和與未達(dá)款之和相同。賬務(wù)服務(wù)除了提供資金轉(zhuǎn)移操作外，還提供資金凍結(jié)與解凍操作。賬務(wù)前置在準(zhǔn)備階段需要針對(duì)資金凍結(jié)與解凍操作進(jìn)行處理。當(dāng)請(qǐng)求資金凍結(jié)時(shí)，首先需要以預(yù)凍結(jié)的方式將相關(guān)資金凍結(jié)起來(lái)，由于 該筆資金被凍結(jié)后只能?？顚Ｓ茫从糜谥付愋偷馁Y金凍結(jié)），因此,在賬務(wù)前置中，需要記錄一筆該專項(xiàng)凍結(jié)的未達(dá)款。當(dāng)請(qǐng)求資金解凍時(shí)，可解凍的額度取決于目前該專項(xiàng)凍結(jié)的資金總額加上 該專項(xiàng)凍結(jié)未達(dá)款的總額，如果滿足解凍條件，需要針對(duì)該專項(xiàng)凍結(jié)記錄 一筆預(yù)解凍。對(duì)于充值類業(yè)務(wù)，由于只涉與到一個(gè)賬戶，因此只需要記錄未達(dá)

20、款即可。對(duì)于提現(xiàn)類業(yè)務(wù)，由于只涉與到一個(gè)賬戶，只需要預(yù)凍結(jié)即可。對(duì)于特殊賬戶，如中間賬戶、特定的大賬戶，可以不進(jìn)行預(yù)凍結(jié)、未達(dá)款計(jì)算。4多參與者模型對(duì)于某些業(yè)務(wù)處理，作為獨(dú)立服務(wù)的參與者可能不止一個(gè)， 在這種情況下, 就需要建立多參與者間的分布式事務(wù)處理模型。事務(wù)管理域業(yè)務(wù)處理域本地事務(wù)域查詢主事務(wù)管理器勾對(duì)開(kāi)始提交回滾主業(yè)務(wù)服務(wù)(1)分支事務(wù) 準(zhǔn)備, J_p 管理器(8)確認(rèn)取消預(yù)操作從業(yè)務(wù)服務(wù)確認(rèn) 事務(wù)恢復(fù)daem on(6)確認(rèn)取消賬務(wù)操作查詢分支事務(wù)準(zhǔn)備管理器 J賬務(wù)確認(rèn)前置賬務(wù)取消 本地事務(wù)域賬務(wù)核心(3)本地事務(wù)域上圖顯示的是一個(gè)三參與者的模型。相比基礎(chǔ)模型，上圖中引入了“從業(yè)務(wù)服

21、務(wù)” (7)，在從業(yè)務(wù)服務(wù)上也有一個(gè)分支事務(wù)管理器(8)。從業(yè)務(wù)服務(wù)的執(zhí)行結(jié)果可以影響主業(yè)務(wù)服務(wù)的執(zhí)行結(jié)果，例如，若紅包支付不成功， 則交易的付款操作不成功。凡是作為“從業(yè)務(wù)服務(wù)”參與到業(yè)務(wù)處理中、并影響主業(yè)務(wù)服務(wù)執(zhí)行結(jié)果的服務(wù)，都需要進(jìn)行改造，將對(duì)應(yīng)的業(yè)務(wù)操作分解為預(yù)操作、確認(rèn)與取消 三個(gè)操作。預(yù)操作完成業(yè)務(wù)處理之前的約束檢查并鎖定資源，但不實(shí)際進(jìn) 行業(yè)務(wù)處理；確認(rèn)操作完成實(shí)際業(yè)務(wù)處理，取消操作完成資源的解鎖。如果從業(yè)務(wù)服務(wù)的執(zhí)行結(jié)果不影響主業(yè)務(wù)服務(wù)的執(zhí)行結(jié)果，則可以不參與 到分布式事務(wù)處理中。在主業(yè)務(wù)處理完成之后，可以通過(guò)異步確保通知 /ESB來(lái)驅(qū)動(dòng)從業(yè)務(wù)服務(wù)完成處理。比如交易成功后的收費(fèi)，收費(fèi)服務(wù)的執(zhí) 行結(jié)果不會(huì)影響交易執(zhí)行結(jié)果，就不必參與到分布式事務(wù)處理中。5實(shí)例分析在