<SOFA:Channel/>，有趣實(shí)用的分布式架構(gòu)頻道。?

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

大家好，我是今天分享的講師仁空，目前是螞蟻金服分布式事務(wù)產(chǎn)品的研發(fā)。今天跟大家分享的是螞蟻金服分布式事務(wù)實(shí)踐解析，也就是分布式事務(wù) Seata 在螞蟻金服內(nèi)部的實(shí)踐。

今天我們將從以下 4 個主題進(jìn)行詳細(xì)介紹：

• 為什么會有分布式事務(wù)產(chǎn)品的需求；

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

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

• 針對螞蟻金服業(yè)務(wù)場景的性能優(yōu)化；

一、分布式事務(wù)產(chǎn)生背景

首先是分布式事務(wù)產(chǎn)生的背景。

支付寶支付產(chǎn)品在 2003 年上線的時候，那時候的軟件形態(tài)是單體應(yīng)用，在一個應(yīng)用內(nèi)完成所有的業(yè)務(wù)邏輯操作。隨著軟件的工業(yè)化，場景越來越復(fù)雜，軟件也越做越大，所有的業(yè)務(wù)在一個應(yīng)用內(nèi)去完成變的不可能，出現(xiàn)了軟件模塊化、服務(wù)化。

在從單體應(yīng)用升級到分布式架構(gòu)過程中，很自然得需要進(jìn)行業(yè)務(wù)服務(wù)拆分，將原來糅在一個系統(tǒng)中的業(yè)務(wù)進(jìn)行梳理，拆分出能獨(dú)立成體系的各個子系統(tǒng)，例如交易系統(tǒng)、支付系統(tǒng)、賬務(wù)系統(tǒng)等，這個過程就是服務(wù)化。業(yè)務(wù)服務(wù)拆分之后，原來一個服務(wù)就能完成的業(yè)務(wù)操作現(xiàn)在需要跨多個服務(wù)進(jìn)行了。

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

二、分布式事務(wù)理論基礎(chǔ)

我們可以看到，在分布式架構(gòu)中，跨數(shù)據(jù)庫、跨服務(wù)的問題是天然存在的。一個業(yè)務(wù)操作的完成，需要經(jīng)過多個服務(wù)配合完成，這些服務(wù)操作的數(shù)據(jù)可能在一個機(jī)房中，也可能跨機(jī)房存在，如果中間某一個服務(wù)因?yàn)榫W(wǎng)絡(luò)或機(jī)房硬件的問題發(fā)生了抖動，怎么保證這筆業(yè)務(wù)最終的狀態(tài)是正確的，比如支付場景，怎么防止我轉(zhuǎn)錢給你的過程中，我的錢扣了，而對方的賬戶并沒有收到錢。這個就是業(yè)務(wù)最終一致性的問題，是分布式事務(wù)需要解決的問題。

2PC 協(xié)議

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

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

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

TCC 協(xié)議

另一個協(xié)議是 TCC 協(xié)議，各個參與者需要實(shí)現(xiàn) 3 個操作：Try、Confirm 和 Cancel，3 個操作對應(yīng) 2 個階段，Try 方法是一階段的資源檢測和預(yù)留階段，Confirm 和 Cancel 對應(yīng)二階段的提交和回滾。

圖中，事務(wù)開啟的時候，由發(fā)起方去觸發(fā)一階段的方法，然后根據(jù)各個參與者的返回狀態(tài)，決定二階段是調(diào) Confirm 還是 Cancel 方法。

三、螞蟻金服分布式事務(wù)介紹

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

分布式事務(wù)在螞蟻金服的發(fā)展

基于上述的理論，接下來我們詳細(xì)看下螞蟻金服的分布式事務(wù)實(shí)現(xiàn)。

經(jīng)過多年的發(fā)展，螞蟻金服內(nèi)部針對不同的場景發(fā)展了幾種不同的模式，最早的是 TCC 模式，也就是上面講的 Try - confirm - Cancel，我們定義接口規(guī)范，業(yè)務(wù)自己實(shí)現(xiàn)這 3 個操作。這個模式提供了更多的靈活性，因?yàn)槭菢I(yè)務(wù)自己實(shí)現(xiàn)的，用戶可以介入兩階段提交過程，以達(dá)到特殊場景下的自定義優(yōu)化及特殊功能的實(shí)現(xiàn)，這個模式能幾乎滿足任何我們想到的事務(wù)場景，比如自定義補(bǔ)償型事務(wù)、自定義資源預(yù)留型事務(wù)、消息事務(wù)等場景。TCC 模式廣泛用于螞蟻金服內(nèi)部各金融核心系統(tǒng)。

這里要強(qiáng)調(diào)一點(diǎn)的是，TCC 模式與底層數(shù)據(jù)庫事務(wù)實(shí)現(xiàn)無關(guān)，是一個抽象的基于 Service 層的概念，也就是說，在 TCC 的范圍內(nèi)，無論是關(guān)系型數(shù)據(jù)庫 MySQL，Oracle，還是 KV 存儲 MemCache，或者列式存儲數(shù)據(jù)庫 HBase，只要將對它們的操作包裝成 TCC 的參與者，就可以接入到 TCC 事務(wù)范圍內(nèi)。

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

XA 模式是依賴于底層數(shù)據(jù)庫實(shí)現(xiàn)的。

Saga 模式是基于沖正模型實(shí)現(xiàn)的一個事務(wù)模式，現(xiàn)在的銀行業(yè)金融機(jī)構(gòu)普遍用的是沖正模型。

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

TCC 模式在螞蟻金服內(nèi)的使用

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

• 參與者，它要實(shí)現(xiàn)全部的三個方法，Try、Confirm 和 Cancel；

• 發(fā)起方，主要是作為協(xié)調(diào)者的角色，編排各個參與者，比如調(diào)用參與者的一階段方法，決策二階段是執(zhí)行提交還是回滾；

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

二階段是通過 Spring 提供的事務(wù)同步器實(shí)現(xiàn)的，發(fā)起方在發(fā)起一個分布式事務(wù)的時候，會注冊一個事務(wù)同步器，當(dāng)發(fā)起方本地事務(wù)結(jié)束的時候，會進(jìn)入事務(wù)同步器的回調(diào)方法中。如果發(fā)起方的本地事務(wù)失敗，則在回調(diào)中自動回滾所有參與者。如果發(fā)起方的本地事務(wù)成功，則二階段自動提交所有參與者。二階段結(jié)束后，刪除所有事務(wù)記錄。?

總結(jié)一下：

事務(wù)發(fā)起方是分布式事務(wù)的協(xié)調(diào)者；

分布式事務(wù)必須在本地事務(wù)模板中進(jìn)行，發(fā)起方本地事務(wù)的最終狀態(tài)（提交或回滾）決定整個分布式事務(wù)的最終狀態(tài)；

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

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

上面講了整個流程以及發(fā)起方的實(shí)現(xiàn)內(nèi)容，現(xiàn)在看下業(yè)務(wù)在實(shí)現(xiàn)參與者的時候，需要遵循以下規(guī)范：

• 業(yè)務(wù)模型分二階段設(shè)計(jì)；

• 冪等控制；

• 并發(fā)控制；

• 允許空回滾；

• 防懸掛控制；

我們逐個了解一下：

• 二階段設(shè)計(jì)

二階段設(shè)計(jì)和冪等控制比較容易明白。二階段設(shè)計(jì)就是一階段的資源預(yù)留和二階段的提交回滾。

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

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

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

看下我們?nèi)粘Ｉ钪谐Ｒ姷膸讉€金融業(yè)務(wù)場景，支出、存入、凍結(jié)、解凍、提現(xiàn)、手續(xù)費(fèi)和銷戶。提現(xiàn)場景，比如信用卡提現(xiàn)至銀行卡，類似 A 到 B 的轉(zhuǎn)賬；手續(xù)費(fèi)，跟轉(zhuǎn)賬類似。

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

首先，看下賬戶表的設(shè)計(jì)，前面說過，在設(shè)計(jì)的時候，需要盡可能減少鎖的時間和鎖的粒度，這里賬戶表有這 4 個字段：當(dāng)前余額、未達(dá)金額、業(yè)務(wù)凍結(jié)金額和預(yù)凍結(jié)金額。用戶看到的余額 = 當(dāng)前金額 - 預(yù)凍結(jié) - 業(yè)務(wù)凍結(jié)金額。

支出（扣款）場景

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

存入場景

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

凍結(jié)場景

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

解凍場景

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

以上分享了接入 TCC 如何進(jìn)行二階段設(shè)計(jì)以及如何進(jìn)行資源預(yù)留，用實(shí)際的金融場景分析了下 TCC 一二階段需要做的事情。因?yàn)槎A段設(shè)計(jì)是 TCC 接入的關(guān)鍵，所以進(jìn)行了重點(diǎn)闡述。接下來我們繼續(xù)看 TCC 設(shè)計(jì)的其他規(guī)范。

• 冪等控制

冪等控制，就是 Try-Confirm-Cancel 三個方法均需要保持冪等性。無論是網(wǎng)絡(luò)數(shù)據(jù)包重傳，還是異常事務(wù)的補(bǔ)償執(zhí)行，都會導(dǎo)致 TCC 服務(wù)的 Try、Confirm 或者 Cancel 操作被重復(fù)執(zhí)行；用戶在實(shí)現(xiàn) TCC 服務(wù)時，需要考慮冪等控制，即 Try、Confirm、Cancel 執(zhí)行一次和執(zhí)行多次的業(yè)務(wù)結(jié)果是一樣的。

• 并發(fā)控制

并發(fā)控制即當(dāng)兩個并發(fā)執(zhí)行的分布式事務(wù)操作同一個賬號時，凍結(jié)的部分是相互隔離的，也就是 T1 凍結(jié)金額只能被事務(wù) 1 使用，T2 凍結(jié)金額只能被事務(wù) 2 使用。凍結(jié)資源與事務(wù) ID 之間建立關(guān)聯(lián)關(guān)系。

• 允許空回滾

首先對空回滾的定義就是 Try 未執(zhí)行，Cancel 先執(zhí)行了。正常是一階段的請求先執(zhí)行，然后才是二階段的請求。出現(xiàn)空回滾的原因，是網(wǎng)絡(luò)丟包導(dǎo)致的，調(diào)用 Try 方法時 RPC timeout 了，分布式事務(wù)回滾，觸發(fā) Cancel 調(diào)用；參與者未收到 Try 請求而收到了 Cancel 請求，出現(xiàn)空回滾。

我們在設(shè)計(jì)參與者時，要支持這種空回滾。

• 防懸掛

懸掛的定義是 Cancel 比 Try 先執(zhí)行。不同于空回滾，空回滾是 Try 方法的請求沒有收到。懸掛是 Try 請求到達(dá)了，只不過由于網(wǎng)絡(luò)擁堵，Try 的請求晚于二階段的 Cancel 方法。

整個流程是這樣的：

• 調(diào)用 TCC 服務(wù) Try 方法，網(wǎng)絡(luò)擁堵（未丟包），RPC超時；

• 分布式事務(wù)回滾；

• TCC 服務(wù) Cancel 被調(diào)用，執(zhí)行了空回滾；整個分布式事務(wù)結(jié)束；

• 被擁堵的 Try 請求到達(dá) TCC 服務(wù)，并被執(zhí)行；出現(xiàn)了二階段 Cancel 請求比一階段 Try 請求先執(zhí)行的情況，TCC 參與者懸掛；

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

FMT 模式在螞蟻金服內(nèi)的使用

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

之前介紹幾個事務(wù)模式的時候，說過 TCC 模式雖然靈活，功能強(qiáng)大，能做很多定制和優(yōu)化，但是使用難度上比較大，業(yè)務(wù)系統(tǒng)要進(jìn)行二階段改造，編碼工作非常多。

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

FMT 還是基于二階段的模型，業(yè)務(wù)只需要關(guān)注一階段實(shí)現(xiàn)自己的業(yè)務(wù) SQL，二階段的自動提交回滾由框架來完成。

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

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

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

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

有了這些信息后，框架就完全能自己去執(zhí)行二階段操作了。比如，當(dāng)事務(wù)需要進(jìn)行二階段提交，因?yàn)樵谝浑A段里業(yè)務(wù) SQL 已經(jīng)執(zhí)行了，二階段只需要把產(chǎn)生的中間數(shù)據(jù)刪掉即可。當(dāng)二階段回滾時，因?yàn)槲覀儽４媪?SQL 執(zhí)行的快照數(shù)據(jù)，所以還原回執(zhí)行前的快照數(shù)據(jù)即可，同時把中間數(shù)據(jù)刪掉。

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

四、極致性能優(yōu)化

最后，我們看看在螞蟻金服內(nèi)部，針對雙十一、雙十二這種大促，為了達(dá)到更好的性能狀態(tài)，做的一些優(yōu)化。

二階段異步化

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

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

同庫模式

另一個優(yōu)化，在事務(wù)記錄上。分布式事務(wù)在推進(jìn)過程中，會記錄事務(wù)日志，如果這個事務(wù)日志是放到 Server 這邊的，發(fā)起方更新事務(wù)狀態(tài)時，需要跨 RPC 調(diào)用到Server方那邊，影響分布式事務(wù)的性能。如果將事務(wù)日志存在業(yè)務(wù)數(shù)據(jù)庫，則每次記錄狀態(tài)的就是業(yè)務(wù)本地執(zhí)行的，減少 RPC 調(diào)用次數(shù)，從而提升了性能。

五、總結(jié)

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

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

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

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

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

本文歸檔在 sofastack.tech。

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

* 點(diǎn)下右下角“在看”

* 到公眾號對話框發(fā)送“衛(wèi)衣”，試試手氣~

* 本期互動獎品“SOFAStack Community?衛(wèi)衣”

?

FinTech:一個單體系統(tǒng)足以撐起銀行持續(xù)交付全球大項(xiàng)目

?

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

?

Java線程池實(shí)現(xiàn)原理及其在美團(tuán)業(yè)務(wù)中的實(shí)踐

?

中臺設(shè)計(jì)和實(shí)踐：海量并發(fā)業(yè)務(wù)中臺，新業(yè)務(wù)秒級接入交易中臺

中生代技術(shù)社區(qū)提供內(nèi)推服務(wù)，對應(yīng)BAT，網(wǎng)易，頭條等大廠對接到用人部門，

有需求請?zhí)砑尤汉匣锶?strong>大白的微信

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

? ?END ? ?? #接力技術(shù)，鏈接價值#

快長按二維碼▲關(guān)注我啊魂淡

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。