支付寶分布式事務設計草案(共17頁)

1、精選優(yōu)質(zhì)文檔-傾情為你奉上支付寶分布式事務架構設計草案1 背景介紹為了應對快速變化的市場需求、持續(xù)增長的業(yè)務量，支付寶系統(tǒng)需要基于SOA進行構建與改造，以應對系統(tǒng)規(guī)模和復雜性的挑戰(zhàn)，更好地進行企業(yè)內(nèi)與企業(yè)間的協(xié)作?；赟OA圖景，整個支付寶系統(tǒng)會拆分成一系列獨立開發(fā)、自包含、自主運行的業(yè)務服務，并將這些服務通過各種機制靈活地組裝成最終用戶所需要的產(chǎn)品與解決方案。支付寶系統(tǒng)將會有類似下圖所示的SOA模型：在SOA的系統(tǒng)架構下，一次業(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é)議的原理如下圖所示：從上圖可見，兩階段提交協(xié)議的關鍵在于“準備”操作。分布式事務協(xié)調(diào)者在第一階段通過對所有的分布式事務參與者請求

3、“準備”操作，達成關于分布式事務一致性的共識。分布式事務參與者在準備階段必須完成所有的約束檢查、并且確保后續(xù)提交或放棄時所需要的數(shù)據(jù)已持久化。在第二隊段，分布式事務協(xié)調(diào)者根據(jù)之前達到的提交或放棄的共識，請求所有的分布式事務參與者完成相應的操作。2.2 最末參與者優(yōu)化(LPO)兩階段提交協(xié)議要求分布式事務參與者實現(xiàn)一個特別的“準備”操作，無論在資源管理器（如數(shù)據(jù)庫）還是在業(yè)務服務中實現(xiàn)該操作都存在效率與復雜性的挑戰(zhàn)。因此，兩階段提交協(xié)議有一個重要的優(yōu)化，稱為“最末參與者優(yōu)化”（Last Participant Optimization），允許兩階段提交協(xié)議中有一個參與者不實現(xiàn)“準備”操作（稱為單

4、階段參與者）。最末參與者優(yōu)化的原理如下圖所示：從上圖可見， LPO中，單階段參與者不需要實現(xiàn)準備操作，只需要提供標準的提交操作即可。分布式事務協(xié)調(diào)者必須等其余兩階段參與者都準備好之后，再請求單階段參與者提交，單階段參與者的提交結果將決定整個分布式事務的結果。本質(zhì)上，LPO是將最后一個參與者的準備操作與提交/放棄操作合并成一個提交操作。最末參與者優(yōu)化方案使得我們能夠利用支付寶業(yè)務的特點，盡量簡化分布式事務的實現(xiàn)。2.3 X/Open模型X/Open組織為基于兩階段協(xié)議的分布式事務處理系統(tǒng)提出了標準的系統(tǒng)參考模型（X/Open事務模型）、以及不同組件間與事務協(xié)調(diào)相關的接口，使不同廠商的產(chǎn)品能夠互操

5、作。X/Open事務模型如下圖所示： 從上圖可以看出，X/Open模型定義了兩個標準接口：TX接口用于應用程序向事務管理器發(fā)起事務、提交事務和回滾事務（即確定事務的邊界和結果）；XA接口用于事務管理器將資源管理器（如數(shù)據(jù)庫、消息隊列等）加入事務、并控制兩階段提交。事務管理器一般由專門的中間件提供、或者在應用服務器中作為一個重要的組件提供。資源管理器如數(shù)據(jù)庫、消息隊列一般也會提供XA支持。通過使用符合X/Open標準的分布式事務處理，能夠簡化分布式事務類應用的開發(fā)。但在現(xiàn)實中，事務管理器與資源管理器對TX/XA協(xié)議的實現(xiàn)上存在效率、可靠性與伸縮性上的風險；在兩階段提交協(xié)議執(zhí)行過程中的異常恢復起來

6、也很困難；而且在SOA體系下當事務需要跨越多個服務（而不是多個資源管理器）時，事務的協(xié)調(diào)與恢復會變得非常復雜。在標準分布式事務管理框架不能滿足需要的情況下，我們需要根據(jù)支付寶業(yè)務與系統(tǒng)的特點，設計并實現(xiàn)自己的分布式事務處理機制。下一節(jié)介紹支付寶分布式事務處理的基礎模型。3 基礎模型3.1 典型業(yè)務處理模式支付寶的主體業(yè)務基本都會在一次業(yè)務處理中進行一次或多次賬務處理。典型的業(yè)務處理模式如下圖所示：這種模式可以概括如下：(1) 支付寶的主體業(yè)務服務在執(zhí)行過程中一般都會涉及到一次或者多次的賬務處理。(2) 業(yè)務服務與賬務服務對業(yè)務處理的最終結果有同等的決定權，兩者都能夠使業(yè)務處理失敗。(3) 當一

7、次業(yè)務處理中涉及到超過兩個參與者時，附加的參與者一般對業(yè)務處理的最終結果沒有決定權，但它們會根據(jù)業(yè)務處理的最終結果完成自己的處理。例如，很多業(yè)務在完成之后都涉及到收費的處理，但一般收費不成功不會影響業(yè)務處理本身的結果。根據(jù)兩參與者的特點，以及賬務服務的中心地位，我們可以根據(jù)“兩階段提交協(xié)議”以及“最末參與者優(yōu)化”原理，設計支付寶分布式事務處理的基礎模型。3.2 基礎模型這一基礎模型如下圖所示：在上圖中，各個主要組件的職責如下：(1) 業(yè)務服務業(yè)務服務負責具體業(yè)務處理，如交易服務、紅包服務等等。(2) 賬務前置賬務前置負責接收、檢查并緩沖從業(yè)務服務發(fā)起的賬務請求。(3) 賬務核心負責記賬并更新分

8、戶余額。(4) 主事務管理器與業(yè)務服務位于同一個本地事務域，負責主事務的啟動、提交與回滾。(5) 分支事務管理器與賬務服務位于同一個本地事務域，負責分支事務的準備，確認與取消。(6) 事務恢復daemon定時運行，負責恢復處于已準備狀態(tài)，但在指定時間閾值內(nèi)尚未確認或者取消的事務。下面我們介紹上述組件如何通過協(xié)作完成一次包含賬務的業(yè)務處理。3.3 準備階段下圖顯示在“準備”階段各個組件間的交互過程。1. 業(yè)務服務(1)首先向主事務管理器請求開始主事務，此時，主事務管理器啟動本地事務，按照一定規(guī)則生成一個對本次處理唯一的txId，記錄主事務日志，并在事務上下文中記錄txId，這個txId在整個分布

9、式事務的生命周期中用于建立主事務與分支事務之間的對應關系，并用于業(yè)務重復性檢查。 2. 業(yè)務服務向賬務前置發(fā)送賬務處理請求。主事務管理器能夠攔截本次請求，并將主事務ID(txId)附加到賬務處理請求的上下文中，一起發(fā)送給賬務前置。3. 賬務前置進行前置約束檢查。前置約束檢查至少要保證：a. 事務Id有效；b. 業(yè)務不重復。前置約束檢查前，相關賬戶必須鎖定（除特定賬戶外、如中間賬戶等）。4. 賬務前置調(diào)用賬務核心進行賬務約束檢查。賬務約束檢查至少要保證：a. 賬戶狀態(tài)正確；b. 賬戶資金足夠；c. 其它賬務約束滿足。賬務約束檢查時必須考慮到在本事務中尚未到達的資金，因此這是檢查中比較特殊的地方，

10、需要恰當處理。5. 賬務前置調(diào)用賬務核心進行資金凍結。對于完成本次賬務處理需要的資金，需要一種特殊的方式凍結起來，但這種凍結沒有業(yè)務含義，因此，不應該記錄資金凍結日志，只是在freeze_amount中增加這筆凍結資金，確保賬務確認階段能夠使用這筆資金。如果本次賬務處理所需要的資金尚未到達，則不需要凍結。6. 賬務前置調(diào)用分支事務管理器記錄分支事務日志。分支事務日志中記錄了本次賬務處理的內(nèi)容以及凍結的金額，在確認階段，分支事務管理器會根據(jù)分支事務日志中記錄的內(nèi)容驅(qū)動賬務系統(tǒng)完成預凍結金額的解凍與實際的賬務處理。7. 賬務前置向業(yè)務服務返回賬務處理的結果。8. 業(yè)務服務根據(jù)賬務處理的結果繼續(xù)進行

11、業(yè)務處理。在一次業(yè)務處理過程上，上述交互過程允許進行發(fā)生多次。但為了控制遠程調(diào)用的成本，也可以將賬務請求打成包合并發(fā)送給賬務前置。3.4 確認階段下圖顯示在“確認”階段各個組件的交互過程。1. 業(yè)務服務請求主事務管理器提交事務。2. 主事務管理器首先完成本地事務的提交。3. 主事務管理器向業(yè)務系統(tǒng)返回事務提交的結果。4. 主事務管理器向分支事務管理器確認分支事務結果。5. 分支事務管理器順序處理對應于本次分布式事務的每一條分支事務日志，對每一條分支事務日志，調(diào)用賬務前置確認該次處理。6. 賬務前置首先請求賬務核心解凍預凍結的資金。7. 賬務前置請求賬務核心進行賬務處理。8. 賬務核心對本次賬務

12、處理進行約束檢查。對于特定的檢查（比如賬戶狀態(tài)是否有效等）是否需要做，視業(yè)務而定。9. 賬務核心進行賬務處理，包含記錄賬務日志并更新賬戶余額等。其它正常賬務處理中需要執(zhí)行的工作也同樣需要做。10. 賬務核心向賬務前置返回賬務處理的結果。11. 賬務前置向分支事務管理器返回賬務確認的結果，分支事務管理器提交本地事務。12. 分支事務管理器請求主事務管理器勾對主事務。勾對的方式可以是刪除主事務記錄，也可以是為主事務記錄打上標志。3.5 回滾階段1. 業(yè)務服務請求主事務管理器回滾事務。2. 主事務管理器回滾本地事務。3. 主事務管理器向業(yè)務系統(tǒng)返回回滾結果。4. 主事務管理器向分支事務管理器請求取消

13、分支事務。5. 分支事務管理器針對每一條分支事務明細，向賬務前置請求取消賬務處理。6. 賬務前置向賬務核心請求解凍預凍結資金。7. 分支事務管理器清除分支事務日志。3.6 恢復階段1. 定時器定期觸發(fā)事務恢復daemon程序，進行事務恢復。定期的間隔可以是每分鐘一次。2. 事務恢復daemon程序向分支事務管理器查詢處于已到期的處于prepare狀態(tài)的分支事務。已到期的具體時間一般是允許的最大事務長度，比如90秒。3. 事務恢復daemon針對每條到期的處于prepare狀態(tài)的分支事務，向主事務管理器查詢主事務狀態(tài)。4. 主事務管理器向事務恢復daemon返回主事務狀態(tài)。5. 事務恢復daem

14、on根據(jù)查詢主事務狀態(tài)的結果，得到需要確認與取消的分支事務列表。如果主事務狀態(tài)是已提交，則表明分支事務需要提交。如果主事務狀態(tài)不存在（即沒有主事務日志），則表明主事務已回滾。這里需要特別注意的是，如果主事務執(zhí)行時間過長，則可能在查詢時主事務還處于執(zhí)行階段，尚未提交。通過限制主事務長度，可以解決這個問題。需要考慮一下有無更好更安全的方案。6. 事務恢復daemon針對每條需要確認的分支事務，請求分支事務管理器確認事務。7. 事務恢復daemon針對每條需要取消的分支事務，請求分支事務管理器取消事務。3.7 預凍結款與未達款計算在準備階段，賬務前置需要計算出預凍結金額，并請求賬務核心凍結該部分金額

15、，確保在確認階段相關的賬務處理有足夠的金額。在一次分布式事務處理中，業(yè)務服務可能多次請求賬務處理，資金可能在多個賬戶間發(fā)生轉(zhuǎn)移。由于在準備階段，賬務前置只負責預凍結資金，而不會進行實際的資金轉(zhuǎn)移，因此對于資金轉(zhuǎn)入賬戶，在準備階段存在“未達款”（應該轉(zhuǎn)入但實際未轉(zhuǎn)入的資金）。在計算預凍結金額時，必須考慮未達款。假設在一次業(yè)務處理中，有以下三次賬務處理：(1) A - (100)-> B: 從A賬戶轉(zhuǎn)100元至B賬戶(2) B - (50)-> C: 從B賬戶轉(zhuǎn)50元至C賬戶(3) C (200)-> D: 從C賬戶轉(zhuǎn)200元至D賬戶則預凍結款與未達款的計算如下表所示：No#AB

16、CD預凍結未達預凍結未達預凍結未達預凍結未達110000100000021000050050003100005015000200從上表可以看出，賬戶前置必須在每一次處理時計算并更新本次處理過程中所涉及到的各個賬戶的預凍結款與未達款。本次處理中涉及到的所有賬戶的預凍結款之和與未達款之和相同。賬務服務除了提供資金轉(zhuǎn)移操作外，還提供資金凍結與解凍操作。賬務前置在準備階段需要針對資金凍結與解凍操作進行處理。當請求資金凍結時，首先需要以預凍結的方式將相關資金凍結起來，由于該筆資金被凍結后只能?？顚Ｓ茫从糜谥付愋偷馁Y金凍結），因此，在賬務前置中，需要記錄一筆該專項凍結的未達款。當請求資金解凍時，可解凍

17、的額度取決于目前該專項凍結的資金總額加上該專項凍結未達款的總額，如果滿足解凍條件，需要針對該專項凍結記錄一筆預解凍。對于充值類業(yè)務，由于只涉及到一個賬戶，因此只需要記錄未達款即可。對于提現(xiàn)類業(yè)務，由于只涉及到一個賬戶，只需要預凍結即可。對于特殊賬戶，如中間賬戶、特定的大賬戶，可以不進行預凍結、未達款計算。4 多參與者模型對于某些業(yè)務處理，作為獨立服務的參與者可能不止一個，在這種情況下，就需要建立多參與者間的分布式事務處理模型。上圖顯示的是一個三參與者的模型。相比基礎模型，上圖中引入了“從業(yè)務服務”(7)，在從業(yè)務服務上也有一個分支事務管理器(8)。從業(yè)務服務的執(zhí)行結果可以影響主業(yè)務服務的執(zhí)行結果，例如，若紅包支付不成功，則交易的付款操作不成功。凡是作為“從業(yè)務服務”參與到業(yè)務處理中、并影響主業(yè)務服務執(zhí)行結果的服務，都需要進行改造，將對應的業(yè)務操作分解為預操作、確認與取消三個操作。預操作完成業(yè)務處理之前的約束檢查并鎖定資源，但不實際進行業(yè)務處理；確認操作完成實際業(yè)務處理，取消操作完成資源的解鎖。如果從業(yè)務服務的執(zhí)行結果不影響主業(yè)務服務的執(zhí)行結果，則可以不參與到分布式事務處理中。在主業(yè)務處理完成之后，可以通過異步確保通知/ESB來驅(qū)動從業(yè)務服務完成處理。比如交易成功后的收費，收費服務的執(zhí)行結果不會影響交易執(zhí)行結