<SOFA:Channel/>，有趣實用的分布式架構頻道。?

本文根據 SOFAChannel#12 直播分享整理，主題：螞蟻金服分布式事務實踐解析?；仡櫼曨l以及 PPT 查看地址見文末。

大家好，我是今天分享的講師仁空，目前是螞蟻金服分布式事務產品的研發。今天跟大家分享的是螞蟻金服分布式事務實踐解析，也就是分布式事務 Seata 在螞蟻金服內部的實踐。

今天我們將從以下 4 個主題進行詳細介紹：

• 為什么會有分布式事務產品的需求；

• 理論界針對這個需求提出的一些理論和解決方案；

• 螞蟻金服在工程上是如何解決這個問題的；

• 針對螞蟻金服業務場景的性能優化；

一、分布式事務產生背景

首先是分布式事務產生的背景。

支付寶支付產品在 2003 年上線的時候，那時候的軟件形態是單體應用，在一個應用內完成所有的業務邏輯操作。隨著軟件的工業化，場景越來越復雜，軟件也越做越大，所有的業務在一個應用內去完成變的不可能，出現了軟件模塊化、服務化。

在從單體應用升級到分布式架構過程中，很自然得需要進行業務服務拆分，將原來糅在一個系統中的業務進行梳理，拆分出能獨立成體系的各個子系統，例如交易系統、支付系統、賬務系統等，這個過程就是服務化。業務服務拆分之后，原來一個服務就能完成的業務操作現在需要跨多個服務進行了。

另一個就是數據庫拆分，分庫分表。原來的單體數據庫存不下的這么多信息，按服務維度拆庫，比如把用戶相關的存一起，形成用戶庫，訂單放一塊形成訂單庫，這個是拆庫的過程；另一個是拆表，用戶信息按照用戶 ID 散列到不同的 DB 中，水平拆分，數據庫的容量增大了。這樣分庫分表之后，寫操作就會跨多個數據庫了。

二、分布式事務理論基礎

我們可以看到，在分布式架構中，跨數據庫、跨服務的問題是天然存在的。一個業務操作的完成，需要經過多個服務配合完成，這些服務操作的數據可能在一個機房中，也可能跨機房存在，如果中間某一個服務因為網絡或機房硬件的問題發生了抖動，怎么保證這筆業務最終的狀態是正確的，比如支付場景，怎么防止我轉錢給你的過程中，我的錢扣了，而對方的賬戶并沒有收到錢。這個就是業務最終一致性的問題，是分布式事務需要解決的問題。

2PC 協議

針對這個問題，理論界也提出了解決方案，其中最為人熟知的就是二階段協議了，簡稱2PC（Two Phase Commitment Protocol）兩階段提交協議。

兩階段提交協議，就是把整個過程分成了兩個階段，這其中，它把參與整個過程的實體分成了兩類角色，一個叫事務管理器或事務協調者，一個叫資源管理器，事務管理器我們也把它叫做事務發起方，資源管理器稱為事務參與者。

兩個階段，第一個階段是資源準備階段，比如我要轉賬，我要先查詢下我的余額夠不夠，夠的話我就把余額資源預留起來，然后告訴發起方“我準備好了”，第二個階段，事務發起方根據各個參與者的反饋，決定事務的二階段操作是提交還是取消。

TCC 協議

另一個協議是 TCC 協議，各個參與者需要實現 3 個操作：Try、Confirm 和 Cancel，3 個操作對應 2 個階段，Try 方法是一階段的資源檢測和預留階段，Confirm 和 Cancel 對應二階段的提交和回滾。

圖中，事務開啟的時候，由發起方去觸發一階段的方法，然后根據各個參與者的返回狀態，決定二階段是調 Confirm 還是 Cancel 方法。

三、螞蟻金服分布式事務介紹

2019年，螞蟻金服跟阿里巴巴共同開源了分布式事務 Seata ，目前 Seata 已經有 TCC、AT、Saga 模式，Seata 意為：Simple Extensible Autonomous Transaction Architecture，是一套一站式分布式事務解決方案。今天的分享也是 Seata 在螞蟻金服內部的實踐。

分布式事務在螞蟻金服的發展

基于上述的理論，接下來我們詳細看下螞蟻金服的分布式事務實現。

經過多年的發展，螞蟻金服內部針對不同的場景發展了幾種不同的模式，最早的是 TCC 模式，也就是上面講的 Try - confirm - Cancel，我們定義接口規范，業務自己實現這 3 個操作。這個模式提供了更多的靈活性，因為是業務自己實現的，用戶可以介入兩階段提交過程，以達到特殊場景下的自定義優化及特殊功能的實現，這個模式能幾乎滿足任何我們想到的事務場景，比如自定義補償型事務、自定義資源預留型事務、消息事務等場景。TCC 模式廣泛用于螞蟻金服內部各金融核心系統。

這里要強調一點的是，TCC 模式與底層數據庫事務實現無關，是一個抽象的基于 Service 層的概念，也就是說，在 TCC 的范圍內，無論是關系型數據庫 MySQL，Oracle，還是 KV 存儲 MemCache，或者列式存儲數據庫 HBase，只要將對它們的操作包裝成 TCC 的參與者，就可以接入到 TCC 事務范圍內。

TCC 模式的好處是靈活性，弊端是犧牲了易用性，接入難度比較大，所有參與者需要進行改造提供 Try - Confirm - Cancel 三個方法。為了解決 TCC 模式的易用性問題，螞蟻金服分布式事務推出了框架管理事務模式（Framework - Managed Transactions，簡稱 FMT），也就是 Seata 中的 AT 模式。FMT 模式解決分布式事務的易用性問題，最大的特點是易于使用、快速接入、對業務代碼無侵入。

XA 模式是依賴于底層數據庫實現的。

Saga 模式是基于沖正模型實現的一個事務模式，現在的銀行業金融機構普遍用的是沖正模型。

這期我們重點講 TCC 和 FMT，關于 Saga 模式，之前 Saga 模式也有專場直播分享過，感興趣的可以看一下之前的直播回顧：《Seata 長事務解決方案 Saga 模式 | SOFAChannel#10 回顧》。

TCC 模式在螞蟻金服內的使用

首先看下 TCC 模式，主要包含一下幾個模塊：

• 參與者，它要實現全部的三個方法，Try、Confirm 和 Cancel；

• 發起方，主要是作為協調者的角色，編排各個參與者，比如調用參與者的一階段方法，決策二階段是執行提交還是回滾；

舉個例子，比如在這個流程圖中，存在一個發起方和兩個參與者，兩個參與者分別實現了 Try、Confirm 和 Cancel 接口，第一階段被包含在發起方的本地事務模版中（圖中黃顏色的兩條虛線就是發起方本地事務的范圍），也就是說發起方負責調用各個參與者的一階段方法，發起方的本地事務結束后，開始執行二階段操作，二階段結束則整個分布式事務結束。?

二階段是通過 Spring 提供的事務同步器實現的，發起方在發起一個分布式事務的時候，會注冊一個事務同步器，當發起方本地事務結束的時候，會進入事務同步器的回調方法中。如果發起方的本地事務失敗，則在回調中自動回滾所有參與者。如果發起方的本地事務成功，則二階段自動提交所有參與者。二階段結束后，刪除所有事務記錄。?

總結一下：

事務發起方是分布式事務的協調者；

分布式事務必須在本地事務模板中進行，發起方本地事務的最終狀態（提交或回滾）決定整個分布式事務的最終狀態；

發起方主職責：開啟一個分布式事務?+?調用參與者一階段方法。發起方實現的時候，首先是開啟一個本地事務，調用 Start 開啟分布式事務，框架會自動注冊一個 Spring 事務同步器，然后發起方發起對參與者 Try 方法的調用，當有一個 Try 方法失敗，則阻斷發起方本地事務，狀態置為回滾；否則，所有的參與者 Try 成功，整個分布式事務的狀態就是提交。框架會利用事務同步器自動去執行參與者的二階段方法；

使用數據庫持久化記錄事務數據，也就是會跟蹤發起方和各個參與者的狀態，我們稱為主事務狀態和分支事務狀態。這樣我們就知道一個大事務整體是處于什么狀態，每個參與者又是什么狀態，當一筆事務失敗時，我們就能撈起那些失敗的參與者，進行補償重試；

上面講了整個流程以及發起方的實現內容，現在看下業務在實現參與者的時候，需要遵循以下規范：

• 業務模型分二階段設計；

• 冪等控制；

• 并發控制；

• 允許空回滾；

• 防懸掛控制；

我們逐個了解一下：

• 二階段設計

二階段設計和冪等控制比較容易明白。二階段設計就是一階段的資源預留和二階段的提交回滾。

比如以扣錢場景為例，賬戶 A 有 100?元，要扣除其中的 30?元。一階段要先檢查資源是否足夠，賬戶余額是否大于等于 30?塊，資源不足則需要立馬返回失敗；資源足夠則把這部分資源預留起來，預留就是鎖資源，鎖的粒度可大可小，盡量是按照最小粒度、盡快釋放的原則來，比如這里引入一個“凍結部分”的字段，“可用余額”在一階段后就能立馬得到釋放，鎖的是凍結字段。

二階段，如果是提交則真正扣除凍結的 30?元；如果是回滾的話，則把凍結部分加回可用余額里。

我們看個具體的客戶案例，網商銀行在使用 TCC 時，劃分了三層，最上一層是具體的業務平臺，承接著外部不斷變化的業務需求；中間是資產交換服務，是事務發起方層，由它來發起和編排各種不同的事務鏈路；最底下一層是事務參與者層，提供最基礎的服務，比如存款核心提供的存入、支出、凍結、解凍服務，借記賬務的各種原子服務等。

看下我們日常生活中常見的幾個金融業務場景，支出、存入、凍結、解凍、提現、手續費和銷戶。提現場景，比如信用卡提現至銀行卡，類似 A 到 B 的轉賬；手續費，跟轉賬類似。

下面重點介紹一下其他 4 個場景：支出（扣款）、存入（記入）、凍結和解凍四個 Case。

首先，看下賬戶表的設計，前面說過，在設計的時候，需要盡可能減少鎖的時間和鎖的粒度，這里賬戶表有這 4 個字段：當前余額、未達金額、業務凍結金額和預凍結金額。用戶看到的余額 = 當前金額 - 預凍結 - 業務凍結金額。

支出（扣款）場景

先來看下支出（扣款）場景下，賬戶表里各字段的數額變化。初始狀態下，顯示的賬戶余額，和當前余額是一致的。TCC 的一階段檢查并預留資源，這里對應的資源是“預凍結金額”字段，預凍結金額設置為 100?元，當前余額不變。因為 100?塊被預凍結了，顯示給用戶的可用余額現在是 900?元。如果二階段是提交的話，就釋放預凍結金額，扣除當前余額，賬戶的當前余額就是 900?元。如果二階段不是提交，是回滾，這里就是把一階段的資源釋放，也就是把預凍結金額釋放回去，顯式的賬戶余額重新變成 1000?元。

存入場景

上面是支出（扣款）場景，再來看下存入的場景。初始狀態還是當前余額和顯式的可用余額都是1000元。因為是存入，一階段的話就是“未達金額”加 100 元，顯示的可用余額還是不變。二階段如果是提交，就把未達金額清除，把這部分的錢加到當前余額，當前余額就是 1100?元了。如果二階段是回滾，直接清除一階段的未達金額即可。

凍結場景

凍結場景則是在一階段是資源預留，就是預凍結，預凍結金額字段設置為 100?元，顯示給用戶的可用余額也要少 100?塊。二階段如果是提交，就是真正凍結，把預凍結金額釋放，添加業務凍結金額。二階段回滾的話，就是把一階段的預凍結釋放。

解凍場景

最后看下解凍場景，一階段檢查賬戶狀態是不是可用，二階段如果提交，就釋放凍結金額，顯示的可用余額就多了 100 元。二階段如果是回滾狀態，就什么都不用做。

以上分享了接入 TCC 如何進行二階段設計以及如何進行資源預留，用實際的金融場景分析了下 TCC 一二階段需要做的事情。因為二階段設計是 TCC 接入的關鍵，所以進行了重點闡述。接下來我們繼續看 TCC 設計的其他規范。

• 冪等控制

冪等控制，就是 Try-Confirm-Cancel 三個方法均需要保持冪等性。無論是網絡數據包重傳，還是異常事務的補償執行，都會導致 TCC 服務的 Try、Confirm 或者 Cancel 操作被重復執行；用戶在實現 TCC 服務時，需要考慮冪等控制，即 Try、Confirm、Cancel 執行一次和執行多次的業務結果是一樣的。

• 并發控制

并發控制即當兩個并發執行的分布式事務操作同一個賬號時，凍結的部分是相互隔離的，也就是 T1 凍結金額只能被事務 1 使用，T2 凍結金額只能被事務 2 使用。凍結資源與事務 ID 之間建立關聯關系。

• 允許空回滾

首先對空回滾的定義就是 Try 未執行，Cancel 先執行了。正常是一階段的請求先執行，然后才是二階段的請求。出現空回滾的原因，是網絡丟包導致的，調用 Try 方法時 RPC timeout 了，分布式事務回滾，觸發 Cancel 調用；參與者未收到 Try 請求而收到了 Cancel 請求，出現空回滾。

我們在設計參與者時，要支持這種空回滾。

• 防懸掛

懸掛的定義是 Cancel 比 Try 先執行。不同于空回滾，空回滾是 Try 方法的請求沒有收到。懸掛是 Try 請求到達了，只不過由于網絡擁堵，Try 的請求晚于二階段的 Cancel 方法。

整個流程是這樣的：

• 調用 TCC 服務 Try 方法，網絡擁堵（未丟包），RPC超時；

• 分布式事務回滾；

• TCC 服務 Cancel 被調用，執行了空回滾；整個分布式事務結束；

• 被擁堵的 Try 請求到達 TCC 服務，并被執行；出現了二階段 Cancel 請求比一階段 Try 請求先執行的情況，TCC 參與者懸掛；

解決懸掛的問題，可以跟蹤事務的執行，如果已經回滾過了，一階段不應該正常執行，這時候要拒絕 Try 的執行。

FMT 模式在螞蟻金服內的使用

接下來我們來看一下 FMT（Framework-Managerment-Transaction）框架管理事務模式。

之前介紹幾個事務模式的時候，說過 TCC 模式雖然靈活，功能強大，能做很多定制和優化，但是使用難度上比較大，業務系統要進行二階段改造，編碼工作非常多。

針對那些對性能要求并不高，業務體量并不大的中小業務，我們推出了 FMT 模式——框架管理事務，從名字上看，就是大部分工作由框架自動完成，業務只需要關注實現自己的業務 SQL 即可。

FMT 還是基于二階段的模型，業務只需要關注一階段實現自己的業務 SQL，二階段的自動提交回滾由框架來完成。

框架托管的二階段，需要基于對一階段的分析。在一階段中，會執行下面幾個步驟：對 SQL 進行解析，提取表的元數據，保存 SQL 執行前的值，執行 SQL，保存執行后的快照，保存行鎖。

下面看下每個階段具體做的事：

查詢操作不涉及事務，我們這里以一個更新操作為例，首先要對操作的 SQL 進行語法語義分析，提取出關于這條記錄的全部信息，包括是屬于哪張表、查詢條件是什么、有哪些字段、這些記錄的主鍵等，這些信息可以通過 JDBC MetaData API 就能拿到。

然后我們開始保存執行前的快照數據，把目標記錄的所有字段的當前值存到 undo log 里，存完后真正執行 SQL，SQL 執行后原來的一些字段值就已經產生變化了，我們把新的快照數據存到 redo log 里。最后把表名稱和記錄主鍵值存到行鎖表，代表當前這個事務正在操作的是哪些記錄。

有了這些信息后，框架就完全能自己去執行二階段操作了。比如，當事務需要進行二階段提交，因為在一階段里業務 SQL 已經執行了，二階段只需要把產生的中間數據刪掉即可。當二階段回滾時，因為我們保存了 SQL 執行的快照數據，所以還原回執行前的快照數據即可，同時把中間數據刪掉。

這里我們知道了 undo 和 redo log 的作用，接下來講講行鎖。行鎖是用來進行并發控制的。當一個事務在操作一條記錄前，會先去行鎖表里查下有沒有這條記錄的鎖信息，如果有，說明當前已經有一個事務搶占了，需要等待那個事務把鎖釋放。圖中，事務 1 在一階段對記錄上鎖，這個時候事務 2 進來，只能等待，等事務 1 二階段提交，把鎖釋放，事務 2 這時候才能加鎖成功。

四、極致性能優化

最后，我們看看在螞蟻金服內部，針對雙十一、雙十二這種大促，為了達到更好的性能狀態，做的一些優化。

二階段異步化

一個是二階段異步化，因為一階段的結果已經能決定整個事務的狀態了，而且資源也都預留好了，剩下的二階段可以等請求峰值過后再去執行。這樣，分布式事務耗時由執行 Try + Confirm 或者 Try + Cancel 縮減成 Try，提高了吞吐量。雖然結果有延遲的，但最終結果無任何影響。

異步的二階段方法，在請求洪峰過后，會由事務恢復服務撈起執行。

同庫模式

另一個優化，在事務記錄上。分布式事務在推進過程中，會記錄事務日志，如果這個事務日志是放到 Server 這邊的，發起方更新事務狀態時，需要跨 RPC 調用到Server方那邊，影響分布式事務的性能。如果將事務日志存在業務數據庫，則每次記錄狀態的就是業務本地執行的，減少 RPC 調用次數，從而提升了性能。

五、總結

以上就是本期分享的全部內容，我們先從事務產生的背景入手，在現在分布式架構的體系結構下，跨服務協同調用是常態，而網絡、數據庫、機器等都具有不可靠性，如果保證這中間操作要么全部成功，要么全部失敗，是大家面臨的共同問題，特別是金融場景下，對解決這個問題更有迫切性，螞蟻金服作為一家金融科技公司，在這方面也進行了探索，積累了很多經驗。

在介紹螞蟻金服的分布式事務中間件之前，先介紹了一些分布式事務的理論背景，包括兩階段協議和 TCC 協議?；诶碚摫尘?#xff0c;重點介紹了螞蟻金服在分布式事務上 TCC、FMT 模式的應用，分享了實現原理和設計規范以及 TCC 二階段設計等。最后介紹了針對雙十一雙十二這種大促活動，如何進行二階段異步化和同庫模式的優化，來支撐零點峰值時的洪峰請求。

以上就是本期分享的全部內容，如果大家對螞蟻金服在分布式事務中的實踐以及 Seata 有問題跟興趣，也可以在群內（群號：30315793）與我們交流。

本期視頻回顧以及 PPT 查看地址

https://tech.antfin.com/community/live/1119/data/980

本文歸檔在 sofastack.tech。

????獎勵支持 SOFAStack 的你~

* 點下右下角“在看”

* 到公眾號對話框發送“衛衣”，試試手氣~

* 本期互動獎品“SOFAStack Community?衛衣”

?

FinTech:一個單體系統足以撐起銀行持續交付全球大項目

?

《程序員修煉之道（第2版）》！屹立20年王者歸來！

?

Java線程池實現原理及其在美團業務中的實踐

?

中臺設計和實踐：海量并發業務中臺，新業務秒級接入交易中臺

中生代技術社區提供內推服務，對應BAT，網易，頭條等大廠對接到用人部門，

有需求請添加群合伙人大白的微信

申請備注（姓名+公司+技術方向）才能通過哦！

? ?END ? ?? #接力技術，鏈接價值#

快長按二維碼▲關注我啊魂淡

總結

以上是生活随笔為你收集整理的亿级流量 | 蚂蚁金服分布式事务实践解析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。