支付寶分布式事務設計草案

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

18、資金轉(zhuǎn)入賬戶，在準備階段存在“未達款” (應該轉(zhuǎn) 入但實際未轉(zhuǎn)入的資金) 。在計算預凍結(jié)金額時，必須考慮未達款。假設在一次業(yè)務處理中，有以下三次賬務處理：(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賬戶則預凍結(jié)款與未達款的計算如下表所示：No#ABCD預凍結(jié)未達預凍結(jié)未達預凍結(jié)未達預凍結(jié)未達110000100000021000050050003100005015000200從上表可以看出，賬戶前置必須在每一次處理時計算并更新本

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

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

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