分散式事務實踐：螞蟻金服核心金融場景下的演進

本文根據尹博學在2018年5月10日在【第九屆中國資料庫技術大會】的現場演講內容整理而成。

講師介紹：

尹博學，螞蟻金服資深技術專家，目前負責數據中間件技術方向。此前在百度負責資料庫內核及集群技術方向。在分散式事務、資料庫高性能/高可靠架構、資料庫內核等領域有較為深入的研究和豐富的工程實踐。

正文:

隨著互聯網技術快速發展，數據規模增大，分散式系統越來越普及，採用分散式資料庫或者跨多個資料庫的應用在中大規模企業普遍存在，而由於網路、機器等不可靠因素，數據不一致問題很容易出現。

而對金融業務來說，它們面向互聯網進行變革時，除了一致性要求外，對高可用、高可擴展性也有極高的要求。這是金融級分散式系統的最大挑戰之一。

在螞蟻金服核心系統提出微服務化時，曾遇到了非常大的技術難題。首先是在服務拆分以後，面臨跨服務的一致性問題;其次，支付寶當時的峰值交易量已經非常高了，在解決一致性問題的同時，還需要兼顧性能。

然而，在當時最常見的還是基於XA協議的分散式事務解決方案，雖然該方案能夠實現跨服務一致性，但是在熱點數據的處理上，卻不能滿足性能需求。

因此，螞蟻金服微服務化過程中急需一種即能保證一致性，又能保證高性能的方案。當時經過一系列調研和討論，最終選擇了以BASE最終一致性思想為基礎，在業務層實現兩階段提交的TCC分散式事務解決方案，該方案既能保證跨服務的最終一致，又能通過業務靈活加鎖的方式大幅減少資源層加鎖時間，高效處理熱點問題。

隨著螞蟻金服業務不斷豐富，業務邏輯越來越複雜，同時螞蟻金融雲上客戶也越來越多，他們對分散式事務解決方案也不只是追求極限性能，也對接入便捷性、實時一致性有了要求。

近日於北京舉行的2018 DTCC中國資料庫技術大會上，螞蟻金服數據中間件負責人尹博學分享了螞蟻金服在分散式事務技術方向上全系列技術方案與產品：TCC、FMT、XA三種各有側重各有優勢的方案。同時也為大家揭示，在這些方案背後的「技術秘密」。

一. 數據一致性問題

1.1 支付寶 SOA 架構演進

最初的支付寶系統架構非常簡單，是一個典型的 Web 系統，交易、支付、賬務系統是沒有分開的，全部集中在一個大工程里，底層用 DB 存儲，Web服務使用Spring等框架開發，最上層使用LB轉發用戶流量。

隨著代碼規模和業務邏輯複雜度的增長，將所有的業務模塊放在一個 Web服務內的缺點日益凸顯。因此推動了服務模塊化拆分，演進成SOA架構，很好地解決了應用的伸縮性問題。

在這個架構中，交易系統、支付系統、賬務系統分別獨立出來了，它們之間的調用靠RPC，除了服務模塊化拆分，還有資料庫的垂直拆分，根據業務系統功能，將資料庫拆分為多個，每個系統使用獨立的資料庫。

1.2 數據一致性問題

數據垂直拆分後，減少了單庫的性能瓶頸，但也帶來了數據一致性的問題。如下圖所示：

一筆轉賬業務需要跨交易、支付、賬務三個系統才能完成整個流程，並且要求這三個系統要麼一起成功，要麼一起失敗。如果有的成功，有的失敗，就有可能造成數據不一致，那麼這個業務行為肯定不會被用戶所理解。所以，我們系統面臨的問題就是 SOA 架構下的數據一致性。

二. 金融級一致性要求與海量並發處理能力

考慮到在解決一致性問題的同時，還要兼顧海量並發處理能力，螞蟻金服內部結合BASE 理論的思想，選擇在業務層實現2PC(兩階段事務提交)的方式來解決該問題。

BASE 理論是指 BA(Basic Availability，基本業務可用性);S(Soft state，柔性狀態);E(Eventual consistency，最終一致性)。該理論認為為了可用性、性能與降級服務的需要，可以適當降低一點一致性的要求，即「基本可用，最終一致」。

一般來講，在傳統的單機資料庫或者集中式存儲資料庫里，對於一致性的要求是實時一致;而對於分散式系統，服務與服務之間已經實現了功能的劃分，邏輯的解耦，也就更容易弱化一致性，允許處理過程中，數據的短暫不一致，只需要保證數據最終達到一致。(BASE 理論的分析可以參考本系列文章的第二篇)。

2.1 TCC(Try-Confirm-Cancel)模型

TCC 分散式事務模型包括三部分，如下所示

·主業務服務：主業務服務為整個業務活動的發起方，服務的編排者，負責發起並完成整個業務活動。

·業務服務：從業務服務是整個業務活動的參與方，負責提供 TCC 業務操作供主業務服務調用

a)初步操作 Try：完成所有業務檢查，預留必須的業務資源。

b)確認操作 Confirm：真正執行的業務邏輯，不作任何業務檢查，只使用 Try 階段預留的業務資源。因此，只要 Try 操作成功，Confirm 必須能成功。另外，Confirm 操作需滿足冪等性，保證一筆分散式事務有且只能成功一次。

c)取消操作 Cancel：釋放 Try 階段預留的業務資源。同樣的，Cancel 操作也需要滿足冪等性。

·業務活動管理器：業務活動管理器管理控制整個業務活動，包括記錄維護 TCC 全局事務的事務狀態和每個從業務服務的子事務狀態，並在業務活動提交時調用所有從業務服務的 Confirm 操作，在業務活動取消時調用所有從業務服務的 Cancel 操作。

根據統計，2017年，DTX在支付寶內部，接入DTX的系統超過100+，支持場景涉及支付、轉賬、理財、保險等，雙十一支持了峰值25.6萬TPS的支付請求，每天處理資金以千億計，確保了資金的絕對安全。

2.1.1 TCC 與 XA 對比 --- 並發性優勢

TCC把兩階段拆分成了兩個獨立的階段，通過資源業務鎖定的方式進行關聯。資源業務鎖定方式的好處在於，既不會阻塞其他事務在第一階段對於相同資源的繼續使用，也不會影響本事務第二階段的正確執行。

▲XA 模型的並發事務

▲TCC 模型的並發事務

從上面的對比可以發現，TCC 模型相比 XA 模型進一步減少了資源鎖的持有時間。XA 模型下，在 Prepare 階段是不會把事務1所持有的鎖資源釋放掉的，如果事務2和事務1爭搶同一個資源，事務2必須等事務1結束之後才能使用該資源。

而在TCC里，因為事務1在Try階段已經提交了，那麼事務2可以獲得互斥資源，不必再等待事務1的Confirm或Cancel階段執行完。也就是說，事務2的Try階段可以和事務1的Confirm或Cancel階段並行執行，從而獲得了一個比較大的並發性能提升。

2.2 極致性能優化

2.2.1 雙十一業務量指數級增長的挑戰

2010年，阿里開始做大促，每年雙十一的零點峰值成 3 倍以上速度增長，如下圖所示：

折線上的點代表著每一年的交易峰值(TPS)。前面講過，每次分散式事務需要協調多個參與方，因此，每年交易峰值乘以一個倍數才是分散式事務框架要協調最終達到一致性狀態的峰值分支事務數量。可以看到，去年的時候已經達到每秒百萬級水平。

其實，2013年是對我們挑戰很大的一年，2013年雙11提出的峰值目標，按照當時大促準備的計算和存儲資源，是無法完成的，怎麼辦?

只能選擇繼續優化事務框架，讓它盡量少消耗資源，並去獲得一個更大的性能提升。我們根據 TCC 模型的特點以及日常開發時積累的經驗，針對性能問題，做了以下兩類優化。

2.2.2 極致性能優化之同庫模式

之前的業務活動管理器是一個單獨的服務，每次啟動業務活動、登記業務操作、提交或回滾業務活動等操作都需要與業務活動管理器交互，並且交互次數與參與者個數成正相關。

因此，為了追求極限性能，將業務活動管理器的遠程存儲替換成本地存儲，如下所示：

減少了RPC的調用，同時還會做一些減少存儲次數的優化，從而獲得性能收益。

通過這種方式，減少RPC調用耗時，大幅降低事務執行時間。同時還針對支付、賬務等訪問頻繁的特殊從業務服務，優化處理過程，不再創建單獨的分支事務記錄，而是將這個信息與主事務記錄合併，在創建主事務記錄的同時，記錄分支事務，最大程度減少與資料庫的交互次數，從而獲得更高的性能收益。

下面是同庫模式優化前後的時序圖對比：

▲優化前時序圖

▲優化後時序圖

其中，綠色方塊表示本地資料庫訪問。可以發現，優化後減少了：(2+n) 次 PRC 延遲 + 1次資料庫訪問延遲(n表示參與者個數)。

2.2.3 極致性能優化之非同步化

從理論上來說，只要業務允許，事務的第二階段什麼時候執行都可以，因此資源已經被業務鎖定，不會有其他事務動用該事務鎖定的資源。如下圖所示：

這就是 TCC 分散式事務模型的二階段非同步化功能，各從業務服務的第一階段執行成功以後，主業務服務就可以提交完成，框架會保證正確記錄事務狀態，然後再由框架非同步的執行各從業務服務的第二階段，從而比較完整的詮釋最終一致性。

大促的尖峰時刻是從零點開始的幾十秒或一分鐘之內，在這個時刻的交易，我們會把二階段的操作從同步轉成非同步，在沖高的那一刻，二階段就停止了，一階段正常扣款，等著交易零點三十分或者夜裡一點開始回落的時候，我們才開始打開二階段，集中做二階段的動作。

優化後，Confirm 階段在空閑時段非同步執行：

1.假設 Confirm 階段與 Try 階段耗時相同，單個事務耗時減少50%

2.資料庫資源消耗減少50%

三. 金融雲場景下接入便捷性需求強烈

3.1 金融雲元年，全金融場景覆蓋

眾所周知，螞蟻金服在近幾年除了支付業務以外，還發展出了很多複雜的金融業務，比如財富、保險、銀行等。同時，在2014年螞蟻金服全面開啟了金融雲時代，也會對外賦能合作方和客戶。在這些新的場景下面，分散式事務產品面臨新的挑戰，客戶的性能需求可能不像螞蟻金服內部要求那麼高，而是更關注接入的便利性和通用性，要求簡單易用，對業務代碼無侵入。因此，分散式事務產品開始全面升級，滿足更多客戶對雲端產品的需求。

3.2 FMT(Framework-managed transactions)模型

TCC 模型作用於業務層，負責協調從業務服務的最終一致性。所有被納入到分散式事務的從業務服務，需要為框架提供Try、Confirm、Cancel三個方法，並且需要滿足冪等性。由於方法實現和要滿足的約束條件都需要業務方提供，這無疑就大大提高了接入門檻。所以我們在 TCC 模型上繼續往前推進發展，提出了 FMT 模型來解決接入便捷性的問題。

FMT模型，這是螞蟻金服分散式事務產品的可託管版本，讓用戶可以基本無侵入的方式下解決分散式事務問題。

FMT 分散式事務模型與 TCC 模型類似，也同樣包含主業務服務、從業務服務、業務活動管理器，如下所示：

不同的是，從業務服務不再需要提供 Try、Confirm、Cancel三個方法，而是直接按照 JDBC 標準，通過託管框架與底層資料庫交互，就像使用普通數據源一樣。託管框架對業務來說是透明的，主要負責解析SQL語義，自動生成兩階段操作。

3.2.1 FMT 模型實現原理

託管框架的兩階段操作如下圖所示：

FMT 框架要求從業務服務只需要正常執行SQL操作就可以了，框架會把業務的本地事務操作作為第一階段。在第一階段，框架會攔截用戶SQL，解析SQL語義，然後把業務SQL涉及數據執行前後的狀態保存下來，即數據快照，這個就相當於在邏輯上完成了資料庫內的undo和redo操作。在第二階段，如果這個事務要提交，那麼框架直接把快照數據刪除就可以了，因為第一階段的正常操作已經執行完成。如果該事務要回滾，那麼會先校驗臟寫，根據第一階段保存的執行後的快照，檢查在本事務執行過程中，數據有沒有被其他操作修改，如果沒有，則把數據執行前的快照拿出來，完成回滾操作。

3.2.1.1 一階段示例

舉個例子，上圖左邊這張表有兩列，一列是賬號，另一列是金額。這時如果要針對該賬戶執行一條update操作，框架會怎麼做呢?

在update之前，會先把賬戶的金額保存下來，執行update操作，然後把執行之後的金額保存下來。因為在二階段有可能會是回滾操作，回滾的時候如果想把執行之前的數據覆蓋回去的話，必須要保證在覆蓋的那個時刻，這些行上面的數據沒有被別人變更過，所以最後會加一個邏輯行鎖，這個就是金融系統的特性需求。

3.2.2 與數據訪問代理集成

為了更加簡化雲上用戶接入，我們繼續和內部產品數據訪問代理DBP合作集成，如下所示：

分散式事務產品框架可以認為是被集成在數據訪問代理里，當進行一個事務時，上層業務方對於底下的分散式事務和本地事務是一視同仁的，通過數據代理看一個事務，並執行SQL。如果是分散式事務，數據訪問代理會通知框架去執行前面提到的一系列保證事務的操作，以保證數據的最終一致。

四. 數據實時一致性、通用性、性能

4.1 XA模型

2018年螞蟻金服推出第三代分散式事務解決方案，即加入XA模式的解決方案，全面支持標準XA協議。該模式覆蓋面廣，可無縫接入支持XA的資料庫、消息等，與自研資料庫OceanBase共同形成實時數據一致性的整體解決方案，極大地降低傳統業務上雲的遷移成本。

事實上，TCC和FMT兩個模型都是在最佳實踐上追求數據的最終一致性，而不是實時一致性。

我們分析了金融雲上的客戶發現，如果把業務模型假定成數據最終一致性，那麼依然有很多金融客戶不得不做出很大的妥協和變更，尤其是原有的業務組織模型和業務邏輯實現。而且這種妥協和調整的工作量是很大的，門檻也是非常高的。同時這些客戶的場景對熱點性能要求沒有那麼嚴苛。

所以我們基於標準XA做了一個XA模型來滿足客戶對數據實時一致性的需求。

原生XA協議提出至今，大概有10-20的時間了，但是在工業界應用的歷史和案子都很少。為什麼會這樣呢?我們認為最重要的一點就是在追求數據實時一致性的同時，性能損失太大了。主要有兩個比較方面的性能損失，一個是讀和寫之間的衝突，另一個是寫與寫之間的衝突。

4.2 標準XA問題分析

了解資料庫內核的人都清楚，資料庫內部解決寫和非加鎖讀的衝突是通過MVCC機制來實現的。假如說最新的數據塊在更新的同時，你的讀是可以讀正在更新的數據塊的上一個快照。但是在分散式架構下，單機 MVCC 機制並不能滿足數據實時性一致性要求。

依然是轉賬業務場景，A 賬戶給 B 賬務轉賬10塊錢。但是 A 賬戶和 B賬戶分別在兩個資料庫分片 DB1 和 DB2 上。其操作執行過程如下所以：

如上圖所示，DB1 的本地子事務已經提交完畢，但是 DB2 的本地子事務還沒提交，這個時候只能讀到 DB1 上子事務執行的內容，讀不到 DB2 上的子事務。也就是說，雖然在單個 DB 上的本地事務是實時一致的，但是從全局來看，一個全局事務執行過程的中間狀態被觀察到了，全局實時一致性就被破壞了。

但是原生的 XA 協議沒有規定快照讀這個概念，也就沒有定義怎麼實現全局實時一致性。最簡單的做法就是使用串列化的隔離級別，即使是快照讀也需要轉換為加鎖讀，從而來保證分散式事務的實時一致性。

當然，由於串列化隔離級別的性能較差，很多分散式資料庫都自己實現了分散式 MVCC 機制來提供全局的實時一致性讀。一個基本思路是用一個集中式或者邏輯上單調遞增的東西來控制生成全局快照(Snapshot)，每個事務或者每條 SQL 執行時都去獲取一次，從而實現不同隔離級別下的全局一致性，如下圖所示：

在 DB1 的本地子事務已經提交完畢，DB2 的本地子事務還沒提交的中間狀態，其他並發事務只能看到該事務執行之前的快照。

我們的分散式事務產品同樣實現了分散式 MVCC 機制，從而在保證實時一致性的同時，最大程度的保證讀寫並發性能。

4.3 並發寫優化 --- 與 OB 深度定製 commit 延遲優化

除了實現分散式 MVCC 保證並發讀寫性能外，我們還與自研資料庫 OceanBase 深度定製優化並發寫，進一步提升產品性能，共同打造實時數據一致性的整體解決方案。

傳統標準的二階段提交過程如下：

其中，綠色方塊表示持久化日誌，黃色方塊表示事務提交。從圖中可以看到，單次 Commit 操作需要有3次日誌延遲、1次事務延遲以及2次 RPC 延遲。

OceanBase 內部實現XA協議的時候，會在和協調者交互的時候附帶一些信息，並且在Commit時落盤，減少Commit過程中涉及到的RPC和落盤的操作，以達到減少用戶Commit時間的效果。

優化後時序圖如下：

雖然在 Commit操作之後，還有 Clear 操作，但是在執行 Clear 時，用戶的Commit請求已經返回了，所以並不影響用戶感知的 Commit 請求延遲。因此，從用戶感知的角度來說，單次 Commit 操作實際上只需要 1次日誌延遲、1次事務延遲 以及 2次RPC延遲。

通過以上優化，兩階段提交與普通提交的落盤次數和RPC次數是相同的，也就是說耗時和普通提交相差無幾，寫和寫之間的衝突所帶來的額外性能消耗將被降低很大一部分。

五. 總結

本文介紹了螞蟻金服在分散式事務上，經過多年發展，服務於內外部大量不同業務，沉澱出的一整套包含TCC、FMT、XA模型的分散式事務解決方案。

首先，為了兼顧海量並發處理能力與一致性的問題，我們基於BASE思想，在業務層實現了TCC 模型，並且優化了其工程實踐，讓它的性能可以達到比業界其它產品高很多的狀態。

其次，因為上層業務系統的複雜、業務種類的豐富等等業務需求，對分散式事務解決方案提出了全新的要求，所以我們在TCC模型基礎上又加入了FMT模型，其簡單易用，對業務無侵入的特點，可以較好的解決金融雲場景下接入便捷性問題。

最後，我們對數據實時一致性、通用性、性能再思考，與自研資料庫 OceanBase 深度定製，推出XA模型，共同打造實時數據一致性的整體分散式事務解決方案。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！