文章綱要
- 此次分享的緣由
- 目前分散式事務問題是怎麼解決的
- 行業中有什麼解決方案
- 這些解決方案分別有什麼優缺點
- 別人是怎麼做的
- 我們可以怎麼來做
此次分享的緣由
支付重構
考慮支付重構的時候，自然想到原本屬於一個本地事務中的處理，現在要跨應用了要怎麼處理。拿充值訂單舉個例子吧，假設：原本訂單模組和賬戶模組是放在一起的，現在需要做服務拆分，拆分成訂單服務，賬戶服務。原本收到充值回撥後，可以將修改訂單狀態和增加金幣放在一個mysql事務中完成的，但是呢，因為服務拆分了，就面臨著需要協調2個服務才能完成這個事務
所以就帶出來，我們今天要分享和討論的話題是：怎麼解決分散式場景下資料一致性問題，暫且用分散式事務 來定義吧。
同樣的問題還存在於其他的場景：
送禮：
1. 呼叫支付服務：先扣送禮使用者的金幣，然後給主播加相應的荔枝
2. 確認第一步成功後，播放特效，發聊天室送禮評論等
複製程式碼充值成功訊息：
- 完成充值訂單
- 傳送訂單完成的kafka訊息
在涉及支付交易等付費介面的時候，資料一致性的問題就顯得尤為重要，因為都是錢啊
目前分散式事務是怎麼解決的呢？
問題肯定不是新問題，也就是目前已經有相應的解決方案了，那就看一下現在是怎麼來解決這類問題的吧。
以購買基礎商品成功後傳送支付訂單完成訊息為例：
假設支付下單購買基礎商品，此刻已經收到支付回撥，訂單已經處理成功了，這個時候kafka服務故障，訊息傳送失敗；而這個時候處理訂單的事務已經提交了，怎麼保證訂單完成的訊息一定能發出去呢？
解讀一下這個流程：
綠色部分，表示流程正常執行的互動過程：
- 先往JobController中提交一個job（用於故障恢復）
- 提交成功後，開始處理訂單邏輯
- 處理完訂單邏輯之後，開始傳送kafka訊息
- 訊息也傳送成功後，刪除第一步提交的job
黃色部分，表示流程出現了異常，資料可能存在不一致現象。這個時候就需要進行流程恢復
- JobController任務控制器定時去redis查詢延時任務列表（每個任務都有一個時間戳，按時間戳排序過濾）
- 將任務進行恢復（呼叫job註冊時定義的處理方法）
- 任務執行成功，表示流程完成；否則下一個定時週期重試
問題：
- 基於redis儲存恢復任務，可能存在資料丟失風險
- 架構體系中沒有統一的分散式事務規範，可否將這層邏輯獨立為分散式事務中介軟體
- 缺少事務執行策略管理，如：控制最大重試次數等
- 事務執行狀態沒有記錄，追查需要去翻看日誌
行業中有什麼解決方案
說解決方案之前，我們先了解一下這些方案的理論依據，有助於幫助我們來理解和實踐這些方案
理論依據（討論的前提）
本地事務、分散式事務
如果說本地事務是解決單個資料來源上的資料操作的一致性問題的話，那麼分散式事務則是為了解決跨越多個資料來源上資料操作的一致性問題。
強一致性、弱一致性、最終一致性
從客戶端角度，多程式併發訪問時，更新過的資料在不同程式如何獲取的不同策略，決定了不同的一致性。對於關係型資料庫，要求更新過的資料能被後續的訪問都能看到，這是強一致性。如果能容忍後續的部分或者全部訪問不到，則是弱一致性。如果經過一段時間後要求能訪問到更新後的資料，則是最終一致性
從服務端角度，如何儘快將更新後的資料分佈到整個系統，降低達到最終一致性的時間視窗，是提高系統的可用度和使用者體驗非常重要的方面。對於分散式資料系統：
- N — 資料複製的份數
- W — 更新資料時需要保證寫完成的節點數
- R — 讀取資料的時候需要讀取的節點數
如果W+R>N，寫的節點和讀的節點重疊，則是強一致性。例如對於典型的一主一備同步複製的關係型資料庫，N=2,W=2,R=1，則不管讀的是主庫還是備庫的資料，都是一致的。
如果W+R<=N，則是弱一致性。例如對於一主一備非同步複製的關係型資料庫，N=2,W=1,R=1，則如果讀的是備庫，就可能無法讀取主庫已經更新過的資料，所以是弱一致性。
CAP理論
分散式環境下（資料分佈）要任何時刻保證資料一致性是不可能的，只能採取妥協的方案來保證資料最終一致性。這個也就是著名的CAP定理。
需要明確的一點是，對於一個分散式系統而言，分割槽容錯性是一個最基本的要求。因為 既然是一個分散式系統，那麼分散式系統中的元件必然需要被部署到不同的節點，否則也就無所謂分散式系統了，因此必然出現子網路。而對於分散式系統而言，網 絡問題又是一個必定會出現的異常情況，因此分割槽容錯性也就成為了一個分散式系統必然需要面對和解決的問題。因此係統架構師往往需要把精力花在如何根據業務 特點在C（一致性）和A（可用性）之間尋求平衡。
BASE 理論
BASE是Basically Available（基本可用）、Soft state（軟狀態）和Eventually consistent（最終一致性）三個短語的縮寫。BASE理論是對CAP中一致性和可用性權衡的結果，其來源於對大規模網際網路系統分散式實踐的總結， 是基於CAP定理逐步演化而來的。BASE理論的核心思想是：即使無法做到強一致性，但每個應用都可以根據自身業務特點，採用適當的方式來使系統達到最終一致性。
BASE理論面向的是大型高可用可擴充套件的分散式系統，和傳統的事物ACID特性是相反的，它完全不同於ACID的強一致性模型，而是通過犧牲強一致性來獲得可用性，並允許資料在一段時間內是不一致的，但最終達到一致狀態。但同時，在實際的分散式場景中，不同業務單元和元件對資料一致性的要求是不同的，因此在具體的分散式系統架構設計過程中，ACID特性和BASE理論往往又會結合在一起。
柔性事務
不同於ACID的剛性事務，在分散式場景下基於BASE理論，就出現了柔性事務的概念。要想通過柔性事務來達到最終的一致性，就需要依賴於一些特性，這些特性在具體的方案中不一定都要滿足，因為不同的方案要求不一樣；但是都不滿足的話，是不可能做柔性事務的。
可見性(對外可查詢)
在分散式事務執行過程中，如果某一個步驟執行出錯，就需要明確的知道其他幾個操作的處理情況，這就需要其他的服務都能夠提供查詢介面，保證可以通過查詢來判斷操作的處理情況。
為了保證操作的可查詢，需要對於每一個服務的每一次呼叫都有一個全域性唯一的標識，可以是業務單據號（如訂單號）、也可以是系統分配的操作流水號（如支付記錄流水號）。除此之外，操作的時間資訊也要有完整的記錄。
冪等操作
冪等性，其實是一個數學概念。冪等函式，或冪等方法，是指可以使用相同引數重複執行，並能獲得相同結果的函式。
f(f(x)) = f(x)
在程式設計中一個冪等操作的特點是其任意多次執行所產生的影響均與一次執行的影響相同。也就是說，同一個方法，使用同樣的引數，呼叫多次產生的業務結果與呼叫一次產生的業務結果相同。 這一個要求其實也比較好理解，因為要保證資料的最終一致性，很多解決防範都會有很多重試的操作，如果一個方法不保證冪等，那麼將無法被重試。 冪等操作的實現方式有多種，如在系統中快取所有的請求與處理結果、檢測到重複操作後，直接返回上一次的處理結果等。
業界方案
兩階段提交（2PC）
XA是X/Open CAE Specification (Distributed Transaction Processing)模型中定義的TM（Transaction Manager）與RM（Resource Manager）之間進行通訊的介面。
在XA規範中，資料庫充當RM角色，應用需要充當TM的角色，即生成全域性的txId，呼叫XAResource介面，把多個本地事務協調為全域性統一的分散式事務。
二階段提交是XA的標準實現。它將分散式事務的提交拆分為2個階段：prepare和commit/rollback。
2PC模型中，在prepare階段需要等待所有參與子事務的反饋，因此可能造成資料庫資源鎖定時間過長，不適合併發高以及子事務生命周長較長的業務場景。兩階段提交這種解決方案屬於犧牲了一部分可用性來換取的一致性。
saga
saga的提出，最早是為了解決可能會長時間執行的分散式事務（long-running process）的問題。所謂long-running的分散式事務，是指那些企業業務流程，需要跨應用、跨企業來完成某個事務，甚至在事務流程中還需要有手工操作的參與，這類事務的完成時間可能以分計，以小時計，甚至可能以天計。這類事務如果按照事務的ACID的要求去設計，勢必造成系統的可用性大大的降低。試想一個由兩臺伺服器一起參與的事務，伺服器A發起事務，伺服器B參與事務，B的事務需要人工參與，所以處理時間可能很長。如果按照ACID的原則，要保持事務的隔離性、一致性，伺服器A中發起的事務中使用到的事務資源將會被鎖定，不允許其他應用訪問到事務過程中的中間結果，直到整個事務被提交或者回滾。這就造成事務A中的資源被長時間鎖定，系統的可用性將不可接受。
而saga，則是一種基於補償的訊息驅動的用於解決long-running process的一種解決方案。目標是為了在確保系統高可用的前提下儘量確保資料的一致性。還是上面的例子，如果用saga來實現，那就是這樣的流程：伺服器A的事務先執行，如果執行順利，那麼事務A就先行提交；如果提交成功，那麼就開始執行事務B，如果事務B也執行順利，則事務B也提交，整個事務就算完成。但是如果事務B執行失敗，那事務B本身需要回滾，這時因為事務A已經提交，所以需要執行一個補償操作，將已經提交的事務A執行的操作作反操作，恢復到未執行前事務A的狀態。這樣的基於訊息驅動的實現思路，就是saga。我們可以看出，saga是犧牲了資料的強一致性，僅僅實現了最終一致性，但是提高了系統整體的可用性。
補償事務（TCC）
TCC 其實就是採用的補償機制，其核心思想是：針對每個操作，都要註冊一個與其對應的確認和補償（撤銷）操作。TCC模型是把鎖的粒度完全交給業務處理。它分為三個階段：
- Try 階段主要是對業務系統做檢測及資源預留
- Confirm 階段主要是對業務系統做確認提交，Try階段執行成功並開始執行 Confirm階段時，預設 Confirm階段是不會出錯的。即：只要Try成功，Confirm一定成功。
- Cancel 階段主要是在業務執行錯誤，需要回滾的狀態下執行的業務取消，預留資源釋放。
下面對TCC模式下，A賬戶往B賬戶匯款100元為例子，對業務的改造進行詳細的分析：
匯款服務和收款服務分別需要實現，Try-Confirm-Cancel介面，並在業務初始化階段將其注入到TCC事務管理器中。
[匯款服務]
Try：
檢查A賬戶有效性，即檢視A賬戶的狀態是否為“轉帳中”或者“凍結”；
檢查A賬戶餘額是否充足；
從A賬戶中扣減100元，並將狀態置為“轉賬中”；
預留扣減資源，將從A往B賬戶轉賬100元這個事件存入訊息或者日誌中；
Confirm：
不做任何操作；
Cancel：
A賬戶增加100元；
從日誌或者訊息中，釋放扣減資源。
[收款服務]
Try：
檢查B賬戶賬戶是否有效；
Confirm：
讀取日誌或者訊息，B賬戶增加100元；
從日誌或者訊息中，釋放扣減資源；
Cancel：
不做任何操作。
複製程式碼由此可以看出，TCC模型對業務的侵入強，改造的難度大。
本地訊息表（非同步確保）
本地訊息表這種實現方式應該是業界使用最多的，其核心思想是將分散式事務拆分成本地事務進行處理，這種思路是來源於ebay。我們可以從下面的流程圖中看出其中的一些細節：
基本思路就是：
訊息生產方，需要額外建一個訊息表，並記錄訊息傳送狀態。訊息表和業務資料要在一個事務裡提交，也就是說他們要在一個資料庫裡面。然後訊息會經過MQ傳送到訊息的消費方。如果訊息傳送失敗，會進行重試傳送。
訊息消費方，需要處理這個訊息，並完成自己的業務邏輯。此時如果本地事務處理成功，表明已經處理成功了，如果處理失敗，那麼就會重試執行。如果是業務上面的失敗，可以給生產方傳送一個業務補償訊息，通知生產方進行回滾等操作。
生產方和消費方定時掃描本地訊息表，把還沒處理完成的訊息或者失敗的訊息再傳送一遍。如果有靠譜的自動對賬補賬邏輯，這種方案還是非常實用的。
事務訊息
事務訊息作為一種非同步確保型事務， 將兩個事務分支通過MQ進行非同步解耦，事務訊息的設計流程同樣借鑑了兩階段提交理論，整體互動流程如下圖所示：
- 事務發起方首先傳送prepare訊息到MQ。
- 在傳送prepare訊息成功後執行本地事務。
- 根據本地事務執行結果返回commit或者是rollback。
- 如果訊息是rollback，MQ將刪除該prepare訊息不進行下發，如果是commit訊息，MQ將會把這個訊息傳送給consumer端。
- 如果執行本地事務過程中，執行端掛掉，或者超時，MQ將會不停的詢問其同組的其它producer來獲取狀態。
- Consumer端的消費成功機制有MQ保證。
有一些第三方的MQ是支援事務訊息的，比如RocketMQ，但是市面上一些主流的MQ都是不支援事務訊息的，比如 RabbitMQ 和 Kafka 都不支援。
盡最大努力通知
最大努力通知方案主要也是藉助MQ訊息系統來進行事務控制，這一點與可靠訊息最終一致方案一樣。看來MQ中介軟體確實在一個分散式系統架構中，扮演者重要的角色。最大努力通知方案是比較簡單的分散式事務方案，它本質上就是通過定期校對，實現資料一致性。
最大努力通知方案的實現
- 業務活動的主動方，在完成業務處理之後，向業務活動的被動方傳送訊息，允許訊息丟失。
- 主動方可以設定時間階梯型通知規則，在通知失敗後按規則重複通知，直到通知N次後不再通知。
- 主動方提供校對查詢介面給被動方按需校對查詢，用於恢復丟失的業務訊息。
- 業務活動的被動方如果正常接收了資料，就正常返回響應，並結束事務。
- 如果被動方沒有正常接收，根據定時策略，向業務活動主動方查詢，恢復丟失的業務訊息
最大努力通知方案的特點
- 用到的服務模式：可查詢操作、冪等操作。
- 被動方的處理結果不影響主動方的處理結果；
- 適用於對業務最終一致性的時間敏感度低的系統；
- 適合跨企業的系統間的操作，或者企業內部比較獨立的系統間的操作，比如銀行通知、商戶通知等；
方案比較
| 屬性 | 2PC | TCC | 本地訊息表 | 事務訊息 | 盡最大努力通知 |
|---|---|---|---|---|---|
| 事務一致性 | 強 | 弱 | 弱 | 弱 | 弱 |
| 複雜性 | 中 | 高 | 低 | 低 | 低 |
| 業務侵入性 | 小 | 大 | 中 | 中 | 中 |
| 使用侷限性 | 大 | 大 | 小 | 中 | 中 |
| 效能 | 低 | 中 | 高 | 高 | 高 |
| 維護成本 | 低 | 高 | 低 | 中 | 中 |
別人是怎麼做的
alipay的分散式事務服務DTS
分散式事務服務（Distributed Transaction Service，簡稱 DTS）是一個分散式事務框架，用來保障在大規模分散式環境下事務的最終一致性。DTS 從架構上分為 xts-client 和 xts-server 兩部分，前者是一個嵌入客戶端應用的 Jar 包，主要負責事務資料的寫入和處理；後者是一個獨立的系統，主要負責異常事務的恢復。
核心概念
在 DTS 內部，我們將一個分散式事務的關聯方，分為發起方和參與者兩類：
發起方： 分散式事務的發起方負責啟動分散式事務，觸發建立相應的主事務記錄。發起方是分散式事務的協調者，負責呼叫參與者的服務，並記錄相應的事務日誌，感知整個分散式事務狀態來決定整個事務是 COMMIT 還是 ROLLBACK。
**參與者：**參與者是分散式事務中的一個原子單位，所有參與者都必須在一階段介面（Prepare）中標註（Annotation）參與者的標識，它定義了 prepare、commit、rollback 3個基本介面，業務系統需要實現這3個介面，並保證其業務資料的冪等性，也必須保證 prepare 中的資料操作能夠被提交（COMMIT）或者回滾（ROLLBACK）。從儲存結構上，DTS 的事務狀態資料可以分為主事務記錄（Activity）和分支事務記錄（Action）兩類：
**主事務記錄 Activity：**主事務記錄是整個分散式事務的主體，其最核心的資料結構是事務號（TX_ID）和事務狀態（STATE），它是在啟動分散式事務的時候持久化寫入資料庫的，它的狀態決定了這筆分散式事務的狀態。
**分支事務記錄 Action：**分支事務記錄是主事務記錄的一個子集，它記錄了一個參與者的資訊，其中包括參與者的 NAME 名稱，DTS 通過這個 NAME 來唯一定位一個參與者。通過這個分支事務資訊，我們就可以對參與者進行提交或者回滾操作。
這應該屬於我們上面所說的TCC模式。
eBay 本地訊息表
本地訊息表這種實現方式的思路，其實是源於ebay，後來通過支付寶等公司的佈道，在業內廣泛使用。其基本的設計思想是將遠端分散式事務拆分成一系列的本地事務。如果不考慮效能及設計優雅，藉助關係型資料庫中的表即可實現。
舉個經典的跨行轉賬的例子來描述。 第一步，扣款1W，通過本地事務保證了憑證訊息插入到訊息表中。 第二步，通知對方銀行賬戶上加1W了。那問題來了，如何通知到對方呢？
通常採用兩種方式：
- 採用時效性高的MQ，由對方訂閱訊息並監聽，有訊息時自動觸發事件
- 採用定時輪詢掃描的方式，去檢查訊息表的資料。
類似使用本地訊息表+訊息通知的還有去哪兒，蘑菇街
各種第三方支付回撥
最大努力通知型。如支付寶、微信的支付回撥介面方式，不斷回撥直至成功，或直至呼叫次數衰減至失敗狀態。
我們可以怎麼來做
2PC/3PC需要資源管理器(mysql, redis)支援XA協議，且整個事務的執行期間需要鎖住事務資源，會降低效能。故先排除。
TCC的模式，需要事務介面提供try,confirm,cancel三個介面，提高了程式設計的複雜性。需要依賴於業務方來配合提供這樣的介面。推行難度大，暫時排除。
最大努力通知型，應用於異構或者服務平臺當中
可以看到ebay的經典模式中，分散式的事務，是通過本地事務+可靠訊息，來達到事務的最終一致性的。但是出現了事務訊息，就把本地事務的工作給涵蓋在事務訊息當中了。所以，接下來要基於事務訊息來套我們的應用場景，看起是否滿足我們對分散式事務產品的要求
Q&A
- 討論DDD （一臉懵逼）
- saga落地
參考
Sharding-Sphere：mp.weixin.qq.com/s/LpebzrHU3…
RocketMQ 正式開源分散式事務訊息：mp.weixin.qq.com/s/Kxk2Ag-7d…
最大努力通知：blog.csdn.net/zsh2050/art…
聊聊分散式事務：www.cnblogs.com/savorboard/…
saga: www.cnblogs.com/netfocus/p/…