傳統(tǒng)的基于
數(shù)據(jù)庫本地事務的解決方案只能保障單個服務的一次處理具備原子性、隔離性、一致性與持久性,但無法保障多個分布服務間處理的一致性。因此,我們必須建立一套分布式服務處理之間的協(xié)調機制,保障分布式服務處理的原子性、隔離性、一致性與持久性。
支付寶為什么需要分布式事務
基于SOA架構,整個支付寶系統(tǒng)會拆分成一系列獨立開發(fā)、自包含、自主運行的業(yè)務服務,并將這些服務通過各種機制靈活地組裝成最終用戶所需要的產品與解決方案。
在多個服務協(xié)同完成一次業(yè)務時,由于業(yè)務約束(如紅包不符合使用條件、賬戶余額不足等)、系統(tǒng)故障(如網絡或系統(tǒng)超時或中斷、數(shù)據(jù)庫約束不滿足等),都可能造成服務處理過程在任何一步無法繼續(xù),使數(shù)據(jù)處于不一致的狀態(tài),產生嚴重的業(yè)務后果,所以我們需要一個分布式事務的解決方案,用來協(xié)調多個服務的業(yè)務一致性。
支付寶的分布式事務框架
支付寶開發(fā)的分布式事務是基于兩階段提交的理論(Two Phase Commit),首先給出兩階段提交的邏輯圖:

為了能夠有效的讓框架進行分布式事務的提交、回滾等動作,框架需要在整個兩階段執(zhí)行過程中記錄下足夠的信息,設計了兩張表來記錄相關信息:
分布式業(yè)務控制活動主表:記錄了全局事務的活動狀態(tài);
原子業(yè)務活動表:記錄了原子業(yè)務活動的狀態(tài);
我們用一個例子來說明:
看一個典型的分布式事務場景。
業(yè)務場景描述: 用戶購買商品,使用支付寶余額支付;
測試方案
分析步驟
角色定位
各分支的業(yè)務活動記錄狀態(tài)
梳理業(yè)務各個場景
驗證梳理場景
恢復&回查機制
角色定位
首先測試人員需要分析所測試的系統(tǒng)處于分布式事務中的哪一個環(huán)節(jié)中,是處于事務的發(fā)起者,還是事務的參與者,不同的角色的定位對于測試分析角度不同,主要有以下的區(qū)別:
發(fā)起者:
分為同庫/異庫模式,主要區(qū)分是控制全局事務狀態(tài)的主事務記錄是否持久化在自己系統(tǒng)的db中;
參與者:
分為本地/遠程模式,主要區(qū)分是是否可以創(chuàng)建嵌套的分布式事務;
各分支的業(yè)務活動記錄狀態(tài)
主事務記錄:
根據(jù)業(yè)務場景的不同,主事務記錄狀態(tài)也會相應改變,主要的狀態(tài)機變化如圖所示,測試人員需要模擬業(yè)務場景來驗證狀態(tài)機的遷轉是否正確;
同庫:初始狀態(tài):I;提交成功:C;提交失敗:I
異庫:初始狀態(tài):U;提交成功:U;提交失敗:U
梳理&驗證業(yè)務場景
分析維度
一階段:預處理:成功/失敗;
二階段:提交/回滾;
預期結果
各個狀態(tài)場景
恢復&回查
恢復:應用使用分布式事務,出現(xiàn)處理失敗的業(yè)務活動,為了確保產生的影響不破壞業(yè)務一致性,我們必須對這些記錄進行恢復處理
回查:對于異庫模式,事務狀態(tài)為U,若提交或回滾失敗,分布式事務總控系統(tǒng)無法感知這筆分布式事務是否執(zhí)行成功,需要業(yè)務系統(tǒng)提供相應的回查接口;
恢復及回查接口需要特別關注,對于分布式事務的正常二階段提交或回滾,業(yè)務場景覆蓋時多半都能check到,但是對于恢復及回查邏輯,很多時候都會遺漏,所以測試人員需要對這塊特別做一個分析