干貨|深入理解分布式事務(wù),這一篇就夠了!
導(dǎo)讀概述????隨著業(yè)務(wù)的快速發(fā)展，業(yè)務(wù)復(fù)雜度越來(lái)越高，大部分互聯(lián)網(wǎng)公司幾乎都會(huì)從單體走向分布式，特別是轉(zhuǎn)向微服務(wù)架構(gòu)，隨之而來(lái)就必然遇到分布事務(wù)這個(gè)難題。
????本文主要介紹一下Seata是如何保證數(shù)據(jù)一致性的,將從以下幾個(gè)方面介紹一下分布式實(shí)現(xiàn)方案
1、介紹一下分布式理論(此部分如果已經(jīng)掌握了可以跳過(guò)，看下面部分分享)
2、什么是Seata
3、Seata AT模式下如何解決分布式事務(wù)，應(yīng)用場(chǎng)景
4、Seata?TCC模式下如何解決分布式事務(wù)、應(yīng)用場(chǎng)景、變種場(chǎng)景使用
5、Seata 下的Saga模式
????本文以下單占庫(kù)存案例為主線分享Seata分布式解決方案。
分布式理論
什么是事務(wù)？
??????指的就是一個(gè)操作單元，在這個(gè)操作單元中的所有操作最終要保持一致的行為，要么所有操作都成功，要么所有的操作都被撤銷。使用事務(wù)目的是什么
說(shuō)明白了就是保證數(shù)據(jù)的一致性。什么是本地事務(wù)呢
????我們常常指的是關(guān)系型數(shù)據(jù)庫(kù)的事務(wù)，關(guān)系型數(shù)據(jù)庫(kù)事務(wù)四大特性:Atomicity（原子性)?：要么都成功，要么都失敗。
Consistency(一致性):?在事務(wù)開(kāi)始之前和事務(wù)結(jié)束以后，數(shù)據(jù)庫(kù)的完整性沒(méi)有被破壞，完整性包括外鍵約束、應(yīng)用定義的等約束不會(huì)被破壞。
Isolation（隔離性):數(shù)據(jù)庫(kù)允許多個(gè)并發(fā)事務(wù)同時(shí)對(duì)其數(shù)據(jù)進(jìn)行讀寫和修改的能力，隔離性可以防止多個(gè)事務(wù)并發(fā)執(zhí)行時(shí)由于交叉執(zhí)行而導(dǎo)致數(shù)據(jù)的不一致。
Durability(持久性):事務(wù)處理結(jié)束后，對(duì)數(shù)據(jù)的修改就是永久的，即便系統(tǒng)故障也不會(huì)丟失。
優(yōu)點(diǎn)：可以保證單機(jī)數(shù)據(jù)庫(kù)層面的數(shù)據(jù)一致性。
為什么要使用分布式事務(wù)
分布式事務(wù)在分布式環(huán)境下，為滿足可用性、性能與降級(jí)服務(wù)的需要，降低一致性與隔離性的要求，一方面遵循 BASE 理論
基本業(yè)務(wù)可用性（Basic Availability）
柔性狀態(tài)（Soft state）
最終一致性（Eventual consistency）
同樣的，分布式事務(wù)也部分遵循 ACID 規(guī)范：
原子性：嚴(yán)格遵循
一致性：事務(wù)完成后的一致性嚴(yán)格遵循；事務(wù)中的一致性可適當(dāng)放寬
隔離性：并行事務(wù)間不可影響；事務(wù)中間結(jié)果可見(jiàn)性允許安全放寬
持久性：嚴(yán)格遵循
分布式事務(wù)常見(jiàn)解決手段有哪些呢？
????????兩階段提交2PC、三階段提交3PC、TCC、SAGA、本地消息表、基于可靠消息保證最終一致、最大努力通知等方案。
????????由于分布式事務(wù)方案，無(wú)法做到完全的ACID的保證，沒(méi)有一種完美的方案，能夠解決掉所有業(yè)務(wù)問(wèn)題。因此在實(shí)際應(yīng)用中，會(huì)根據(jù)業(yè)務(wù)的不同特性，選擇最適合的分布式事務(wù)方案。什么是分布式事務(wù)呢？
1、分布式事務(wù)：- 首先應(yīng)用于分布式系統(tǒng)場(chǎng)景，分布式事務(wù)是指事務(wù)的參與者、支持事務(wù)的服務(wù)器、資源服務(wù)器以及事務(wù)管理器分別位于不同的分布式系統(tǒng)的不同節(jié)點(diǎn)之上。
- 例如在電商系統(tǒng)中，下單接口通常會(huì)扣減庫(kù)存、添加優(yōu)惠券、生成訂單 id, 而訂單服務(wù)與庫(kù)存、添加優(yōu)惠券、下單接口的成功與否，不僅取決于本地的 db 操作，而且依賴第三方系統(tǒng)的結(jié)果，這時(shí)候分布式事務(wù)就保證這些操作要么全部成功，要么全部失敗。本質(zhì)上來(lái)說(shuō)，分布式事務(wù)就是為了保證不同數(shù)據(jù)庫(kù)的數(shù)據(jù)一致性。
提到分布式場(chǎng)景就繞不開(kāi)CAP理論，三者只能滿足兩點(diǎn)，來(lái)解決分布式場(chǎng)景的問(wèn)題，那么接下來(lái)先了解一下什么是CAP。
CAP原則
??? CAP 原則又稱 CAP 定理，又被叫作布魯爾定理，指的是在一個(gè)分布式系統(tǒng)中， Consistency（一致性）、 Availability（可用性）、Partition tolerance（分區(qū)容錯(cuò)性），三者不可得兼。
??? CAP 原則的精髓就是要么AP，要么CP，要么AC，但是不存在CAP。如果在某個(gè)分布式系統(tǒng)中數(shù)據(jù)無(wú)副本,那么系統(tǒng)必然滿足強(qiáng)一致性條件,因?yàn)橹挥歇?dú)一數(shù)據(jù)，不會(huì)出現(xiàn)數(shù)據(jù)不一致的情況，此時(shí)C和P兩要素具備，但是如果系統(tǒng)發(fā)生了網(wǎng)絡(luò)分區(qū)狀況或者宕機(jī)，必然導(dǎo)致某些數(shù)據(jù)不可以訪問(wèn),此時(shí)可用性條件就不能被滿足，即在此情況下獲得了CP系統(tǒng)，但是CAP不可同時(shí)滿足。
????即要保證數(shù)據(jù)一致還要保證可用,魚(yú)和熊掌不可兼得，那么就要取舍，于是產(chǎn)生以下幾種一致性策略。強(qiáng)一致性、弱一致性、最終一致性
1.強(qiáng)一致性
????任何一次讀都能讀到某個(gè)數(shù)據(jù)的最近一次寫的數(shù)據(jù)。系統(tǒng)中的所有進(jìn)程，看到的操作順序，都和全局時(shí)鐘下的順序一致。簡(jiǎn)言之，在任意時(shí)刻，所有節(jié)點(diǎn)中的數(shù)據(jù)是一樣的。如：2PC、3PC、XA都屬于強(qiáng)一致性方案。
2.弱一致性????數(shù)據(jù)更新后，如果能容忍后續(xù)的訪問(wèn)只能訪問(wèn)到部分或者全部訪問(wèn)不到，則是弱一致性。3.最終一致性????不保證在任意時(shí)刻任意節(jié)點(diǎn)上的同一份數(shù)據(jù)都是相同的，但是隨著時(shí)間的遷移，不同節(jié)點(diǎn)上的同一份數(shù)據(jù)總是在向趨同的方向變化。簡(jiǎn)單說(shuō)，就是在一段時(shí)間后，節(jié)點(diǎn)間的數(shù)據(jù)會(huì)最終達(dá)到一致?tīng)顟B(tài)。如：TCC和消息隊(duì)列模式、Saga模式屬于最終一致性的解決方案。了解了分布式事務(wù)中的強(qiáng)一致性和最終一致性理論，下面介紹幾種常見(jiàn)的分布式事務(wù)的解決方案。
? ? Seata 分布式事務(wù)
什么是Seata?
????????Seata是一款阿里巴巴開(kāi)源的分布式事務(wù)解決方案，致力于提供高性能和簡(jiǎn)單易用的分布式事務(wù)服務(wù)。Seata將為用戶提供了 AT、TCC、SAGA 和 XA 事務(wù)模式，為用戶打造一站式的分布式解決方案。
什么是Seata 的AT模式？
????AT模式的特點(diǎn)就是對(duì)業(yè)務(wù)無(wú)入侵式，整體機(jī)制分二階段提交- ?基于支持本地 ACID 事務(wù)的關(guān)系型數(shù)據(jù)庫(kù)。
- Java 應(yīng)用，通過(guò) JDBC 訪問(wèn)數(shù)據(jù)庫(kù)。
二階段：????????提交異步化，非常快速地完成；回滾通過(guò)一階段的回滾日志進(jìn)行反向補(bǔ)償。
Seata術(shù)語(yǔ)：
TC (Transaction Coordinator) 事務(wù)協(xié)調(diào)者 ：維護(hù)全局和分支事務(wù)的狀態(tài)，驅(qū)動(dòng)全局事務(wù)提交或回滾。
TM (Transaction Manager) 事務(wù)管理器：定義全局事務(wù)的范圍：開(kāi)始全局事務(wù)、提交或回滾全局事務(wù)。
- RM (Resource Manager) 資源管理器：管理分支事務(wù)處理的資源，與TC交談以注冊(cè)分支事務(wù)和報(bào)告分支事務(wù)的狀態(tài)，并驅(qū)動(dòng)分支事務(wù)提交或回滾。
Seata 的AT模式使用場(chǎng)景
???????怎么理解AT模式呢，咱們以占用庫(kù)存和創(chuàng)建訂單為例：
TM端功能包括【占用庫(kù)存】和【創(chuàng)建訂單】的操作，使用@GlobalTransaction進(jìn)行全局事務(wù)開(kāi)啟、提交、回滾。
TM開(kāi)始RPC調(diào)用遠(yuǎn)程服務(wù)調(diào)用分支【庫(kù)存】服務(wù)和【創(chuàng)建訂單】服務(wù)。
RM端seata-client通過(guò)擴(kuò)展DataSourceProxy，實(shí)現(xiàn)自動(dòng)生成undo_log與TC上報(bào)。
TM告知TC提交/回滾全局事務(wù)。
TC通知RM各自執(zhí)行commit/rollback操作，同時(shí)清除undo_log。
- TM開(kāi)啟全局事務(wù)。
- 庫(kù)存注冊(cè)分支事務(wù),獲取全局鎖。
- 本地事務(wù)提交:插入前鏡像beforeImage->undolog日志，占用庫(kù)存,插入后鏡像afterImage->undolog日志,生成undo log一并提交，將本地事務(wù)提交的結(jié)果上報(bào)給TC。
- 創(chuàng)建訂單注冊(cè)分支事務(wù),獲取全局鎖。
- 本地事務(wù)提交:插入前鏡像beforeImage->undolog日志，創(chuàng)建訂單成功,插入后鏡像afterImage->undolog日志,生成undo log一并提交，將本地事務(wù)提交的結(jié)果上報(bào)給TC。
第二階段：提交或回滾
- 場(chǎng)景1.如果占用庫(kù)存成功 訂單創(chuàng)建成功，則提交全局事務(wù)結(jié)束，刪除本地undolog記錄
場(chǎng)景2.如果占用庫(kù)存或訂單創(chuàng)建某一方失敗，則反向操作undolog回滾日志，刪除本地undlog記錄。
AT模式下如何保證數(shù)據(jù)一致的？
一階段提交如何保持一致性？
TM：method下單服務(wù)方法執(zhí)行時(shí)，由于該方法具有@GlobalTranscational標(biāo)志，該TM會(huì)向TC發(fā)起全局事務(wù)，生成XID（全局鎖）。
RM寫表的過(guò)程，Seata 會(huì)攔截業(yè)務(wù)SQL，首先解析 SQL 語(yǔ)義，在業(yè)務(wù)數(shù)據(jù)被更新前，將其保存成before image，然后執(zhí)行業(yè)務(wù)SQL，在業(yè)務(wù)數(shù)據(jù)更新之后，再將其保存成after image，最后生成行鎖。以上操作全部在一個(gè)數(shù)據(jù)庫(kù)事務(wù)內(nèi)完成，這樣保證了一階段操作的原子性。
因?yàn)椤皹I(yè)務(wù) SQL”在一階段已經(jīng)提交至數(shù)據(jù)庫(kù)， 所以 Seata 框架只需將一階段保存的快照數(shù)據(jù)和行鎖刪掉，完成數(shù)據(jù)清理即可。
正常：TM執(zhí)行成功，通知TC全局提交，TC此時(shí)通知所有的RM提交成功，刪除UNDO_LOG回滾日志。
異常階段如何保持一致性？
什么是Seata 的TCC模式？
??????? TCC 模式需要用戶根據(jù)自己的業(yè)務(wù)場(chǎng)景實(shí)現(xiàn) Try、Confirm 和 Cancel 三個(gè)操作；事務(wù)發(fā)起方在一階段執(zhí)行 Try 方式，在二階段提交執(zhí)行 Confirm 方法，二階段回滾執(zhí)行 Cancel 方法- 一階段 ：Try 資源的檢測(cè)和預(yù)留。
- 二階段 commit 或 rollback回滾行為。
Confirm：執(zhí)行的業(yè)務(wù)操作提交；要求 Try 成功 Confirm 一定要能成功。
Cancel：預(yù)留資源釋放。
- 一階段 prepare 行為：調(diào)用自定義的 prepare 邏輯，Try 資源的檢測(cè)和預(yù)留。
- 二階段 commit 行為：調(diào)用自定義的 commit 邏輯，執(zhí)行的業(yè)務(wù)操作提交；要求 Try 成功Confirm 一定要能成功，失敗則重試。
- 二階段 rollback 行為：調(diào)用自定義的 rollback 邏輯，預(yù)留資源釋放。
Seata 的TCC模式使用場(chǎng)景
????怎么理解TCC模式呢，咱們還以下單扣庫(kù)存為例，Try 階段去占庫(kù)存，Confirm 階段則實(shí)際扣庫(kù)存，如果庫(kù)存扣減失敗 Cancel 階段進(jìn)行回滾，釋放庫(kù)存。
TCC不存在資源阻塞的問(wèn)題,因?yàn)槊總€(gè)方法都直接進(jìn)行事務(wù)的提交，一旦出現(xiàn)異常通過(guò)則 Cancel 來(lái)進(jìn)行回滾補(bǔ)償，這也就是常說(shuō)的補(bǔ)償性事務(wù),拆解流程請(qǐng)看下圖:占用庫(kù)存storage TCC流程圖如下：
- try： 凍結(jié)庫(kù)存操作。
- confirm： 占用庫(kù)存操作。
- cancel： 回滾事務(wù)，直接調(diào)用回滾庫(kù)存接口。
- try： 新增訂單-狀態(tài)更新成【創(chuàng)建中】。
- confirm： try成功，下單操作成功,訂單狀態(tài)由【創(chuàng)建中】更新成【創(chuàng)建成功】。
- cancel： 回滾事務(wù)，刪除該訂單記錄。
小結(jié)：
????????當(dāng)占用庫(kù)存成功同時(shí)訂單下成功時(shí),提交全局事務(wù),當(dāng)接入TCC模式,最重要的事情就是考慮如何將業(yè)務(wù)模型拆成2階段，實(shí)現(xiàn)成TCC的3個(gè)方法，并且保證Try成功Confirm一定能成功。相對(duì)于AT模式,TCC模式對(duì)業(yè)務(wù)代碼有一定的侵入性，但是TCC模式無(wú)AT模式的全局行鎖,TCC性能會(huì)比AT模式高很多。Seata 的TCC模式變種實(shí)現(xiàn)方案？
在說(shuō)TCC變種簡(jiǎn)化變種方案前，先說(shuō)一說(shuō)現(xiàn)實(shí)的業(yè)務(wù)場(chǎng)景：????現(xiàn)實(shí)業(yè)務(wù)并不一定如我們所愿，在業(yè)務(wù)已成規(guī)模，訂單系統(tǒng) 和 庫(kù)存系統(tǒng)，都是在分布式場(chǎng)景，各自的業(yè)務(wù)接口，各自的DB表，如何保證數(shù)據(jù)一致呢？已實(shí)現(xiàn)邏輯采用業(yè)務(wù)代碼異常調(diào)用返向補(bǔ)償實(shí)現(xiàn)的，偽代碼如下：
try{???占用庫(kù)存()???try{???下單方法()???}cach(){???釋放庫(kù)存();???取消訂單();???}??}cach(){??釋放庫(kù)存();}
庫(kù)存服務(wù)：1.占用庫(kù)存接口 2.釋放庫(kù)存接口。
訂單服務(wù)：1.下單接口 2.取消訂單接口。
流程圖如下：
基于現(xiàn)有邏輯如何改造成分布式事務(wù)實(shí)現(xiàn)方案呢？
方案1:采用AT模式，需要做的工作：
在業(yè)務(wù)庫(kù) 訂單數(shù)據(jù)庫(kù)和庫(kù)存數(shù)據(jù)庫(kù) 分別創(chuàng)建undo_log日志。
RM端(庫(kù)存業(yè)務(wù)和訂單業(yè)務(wù)代碼)seata-client通過(guò)擴(kuò)展DataSourceProxy，實(shí)現(xiàn)自動(dòng)生成undo_log與tc上報(bào)，需要業(yè)務(wù)嵌入代碼實(shí)現(xiàn)。
缺點(diǎn)：需要對(duì)庫(kù)存業(yè)務(wù)庫(kù)和訂單業(yè)務(wù)庫(kù)存分別存加 undo_log表，事務(wù)相對(duì)比較長(zhǎng)。
方案2:采用Seata TCC模式
try階段：提供凍結(jié)庫(kù)存方法 和 預(yù)占用訂單方法 需要改造庫(kù)存表和訂單表提供中間狀態(tài)標(biāo)識(shí)。
confirm階段:提供占用庫(kù)存方法和下單成功方法。
cancel階段：提供返向 釋放庫(kù)存和取消訂單方法。
缺點(diǎn)：業(yè)務(wù)代碼要寫庫(kù)存鎖定狀態(tài)業(yè)務(wù)邏輯+訂單創(chuàng)建中的中間態(tài)。
???? 從上面兩個(gè)方案不難看出都有一個(gè)通病，都需要業(yè)務(wù)代碼改造，侵入強(qiáng)，耦合度高，能否有一種，即不需要業(yè)務(wù)代碼改造成本又低的方案呢？
方案3:接下來(lái)的方案是在TCC模式上做了些簡(jiǎn)化：
即在try階段：直接占庫(kù)存成功和下單成功。
在confirm階段：不做業(yè)務(wù)處理，直接返回true，認(rèn)為是成功的。
rollback階段：做返回的取消操作即可。
缺點(diǎn)：浪費(fèi)了一次commit空提交 IO交互。
優(yōu)點(diǎn)：業(yè)務(wù)侵入性小，可以適應(yīng)現(xiàn)有業(yè)務(wù)場(chǎng)景，偶合度低。
簡(jiǎn)化版本的TCC實(shí)現(xiàn)方案的時(shí)序圖如下：
Seata TCC分布式場(chǎng)景下如何保證冪等呢?
首先說(shuō)一下什么是冪等?冪等意思：通常指對(duì)同一個(gè)系統(tǒng),使用同樣的條件,一次請(qǐng)求和重復(fù)的多次請(qǐng)求對(duì)系統(tǒng)資源的影響是一致的.因?yàn)榫W(wǎng)絡(luò)抖動(dòng)或擁堵可能會(huì)超時(shí),事務(wù)管理器會(huì)對(duì)資源進(jìn)行重試操作,所以很可能一個(gè)業(yè)務(wù)操作會(huì)被重復(fù)調(diào)用,為了不因?yàn)橹貜?fù)調(diào)用而多次占用資源，造成業(yè)務(wù)臟數(shù)據(jù)，就需要保證冪等性。如何保證冪等呢?????此時(shí)需要對(duì)服務(wù)設(shè)計(jì)時(shí)進(jìn)行冪等控制,通常我們可以用事務(wù)xid或業(yè)務(wù)主鍵判重來(lái)控制，或采用業(yè)務(wù)唯一標(biāo)識(shí)來(lái)做冪等，總之還是需要業(yè)務(wù)自己來(lái)保證冪等的。Seata下的Saga模式？
1.Saga 是一種補(bǔ)償協(xié)議,Saga 理論出自 Hector & Kenneth 1987發(fā)表的論文 Sagas,其核心思想是將長(zhǎng)事務(wù)拆分為多個(gè)本地短事務(wù)。解決了什么問(wèn)題？2.Saga模式是seata提供的長(zhǎng)事務(wù)解決方案，在Saga模式中，業(yè)務(wù)流程中每個(gè)參與者都提交本地事務(wù)，當(dāng)出現(xiàn)某一個(gè)參與者失敗則補(bǔ)償前面已經(jīng)成功的參與者，一階段正向服務(wù)和二階段補(bǔ)償服務(wù)都由業(yè)務(wù)開(kāi)發(fā)實(shí)現(xiàn)。
如圖：T1~T3都是正向的業(yè)務(wù)流程，都對(duì)應(yīng)著一個(gè)沖正逆向補(bǔ)償操作C1~C3
適用場(chǎng)景：- 業(yè)務(wù)流程長(zhǎng)、業(yè)務(wù)流程多。
- 參與者包含其它公司或遺留系統(tǒng)服務(wù)，無(wú)法提供 TCC 模式要求的三個(gè)接口。
- 一階段提交本地事務(wù)，無(wú)鎖，高性能。
- 事件驅(qū)動(dòng)架構(gòu)，參與者可異步執(zhí)行，高吞吐。
- 補(bǔ)償服務(wù)易于實(shí)現(xiàn)。
? ??seata分布式事務(wù)常見(jiàn)問(wèn)題
常見(jiàn)問(wèn)題答疑
問(wèn)：Seata框架如何來(lái)保證事務(wù)的隔離性的？
答：因seata一階段本地事務(wù)已提交，為防止其他事務(wù)臟讀臟寫需要加強(qiáng)隔離。
??? 1.讀隔離:Seata（AT 模式）的默認(rèn)全局隔離級(jí)別是讀未提交，必須要求全局的讀已提交 ，目前 Seata 的方式是通過(guò)select語(yǔ)句加for update代理方法增加@GlobalLock+@Transactional或@GlobalTransaction實(shí)現(xiàn)。
????2.寫隔離:
一階段本地事務(wù)提交前，需要確保先拿到全局鎖 。
拿不到全局鎖 ，不能提交本地事務(wù)。
拿 全局鎖 的嘗試被限制在一定范圍內(nèi)，超出范圍將放棄，并回滾本地事務(wù)，釋放本地鎖。
答:1.臟數(shù)據(jù)需手動(dòng)處理，根據(jù)日志提示修正數(shù)據(jù)或者將對(duì)應(yīng)undo刪除（可自定義實(shí)現(xiàn)FailureHandler做郵件通知或其他人工介入操作）。
?????? 2.關(guān)閉回滾時(shí)undo鏡像校驗(yàn)，不推薦該方案。
注意事項(xiàng)：建議事前做好隔離保證無(wú)臟數(shù)據(jù)。
問(wèn)：Seata支持哪些RPC框架？
答：1. AT 模式支持:Dubbo、Spring Cloud、Motan、GRPC 和 Sofa-RPC。
2. TCC 模式支持:Dubbo、Spring Cloud和Sofa-RPC。
問(wèn)：Seata現(xiàn)階段支持哪些分庫(kù)分表解決方案?答：現(xiàn)階段只支持ShardingSphere。
答：支持
1.tc使用db模式共享全局事務(wù)會(huì)話信息，注冊(cè)中心使用非file的seata支持的第三方注冊(cè)中心。
2.注冊(cè)中心包含：eureka、consul、nacos、etcd、zookeeper、sofa、redis、file (直連)。
小結(jié)：
在當(dāng)前的技術(shù)發(fā)展階段,不存一個(gè)分布式事務(wù)處理機(jī)制可以完美滿足所有場(chǎng)景的需求。一致性、可靠性、易用性、性能等諸多方面的系統(tǒng)設(shè)計(jì)約束,需要用不同的事務(wù)處理機(jī)制去滿足。
目前使用的流行度情況是：AT>TCC > Saga，Seata 項(xiàng)目最核心的價(jià)值在于:構(gòu)建一個(gè)全面解決分布式事務(wù)問(wèn)題的標(biāo)準(zhǔn)化平臺(tái)。基于 Seata,上層應(yīng)用架構(gòu)可以根據(jù)實(shí)際場(chǎng)景的需求，靈活選擇合適的分布式事務(wù)解決方案。
分布式方案對(duì)比
Seata針對(duì)不同的業(yè)務(wù)場(chǎng)景提供了四種不同的事務(wù)模式，對(duì)比如下:
AT模式：AT 模式的一階段、二階段提交和回滾（借助undo_log表來(lái)實(shí)現(xiàn)）均由 Seata 框架自動(dòng)生成，用戶只需編寫“業(yè)務(wù)SQL”，便能輕松接入分布式事務(wù)，AT 模式是一種對(duì)業(yè)務(wù)無(wú)任何侵入的分布式事務(wù)解決方案。
TCC模式：相對(duì)于 AT 模式，TCC 模式對(duì)業(yè)務(wù)代碼有一定的侵入性，但是 TCC 模式無(wú) AT 模式的全局行鎖，TCC 性能會(huì)比 AT模式高很多。適用于核心系統(tǒng)等對(duì)性能有很高要求的場(chǎng)景。
SAGA模式：Sage 是長(zhǎng)事務(wù)解決方案，事務(wù)驅(qū)動(dòng)，使用那種存在流程審核的業(yè)務(wù)場(chǎng)景。
XA模式：XA模式是分布式強(qiáng)一致性的解決方案，但性能低而使用較少。
?
????????本文介紹了分布式事務(wù)的一些基礎(chǔ)理論，主要對(duì)Seata分布式事務(wù)方案進(jìn)行了講解，在文章的后半部分主要給出了各種方案的常用場(chǎng)景。分布式事務(wù)本身就是一個(gè)技術(shù)難題，業(yè)務(wù)中具體使用哪種方案還是需要根據(jù)自身業(yè)務(wù)特點(diǎn)自行選擇，每種方案在實(shí)際執(zhí)行過(guò)程中需要考慮的點(diǎn)都非常多，復(fù)雜度較大，所以在非必要的情況下，分布式事務(wù)能不用就盡量不用,希望對(duì)大家有所幫助,如果感覺(jué)有所收獲，可以動(dòng)動(dòng)小手指給點(diǎn)個(gè)贊，感謝閱讀!
—————END—————
推薦閱讀
干貨|如何步入Service Mesh微服務(wù)架構(gòu)時(shí)代
實(shí)戰(zhàn)|Service Mesh微服務(wù)架構(gòu)實(shí)現(xiàn)服務(wù)間gRPC通信
再見(jiàn)Nacos，我要玩Service Mesh了！
玩轉(zhuǎn)Service Mesh微服務(wù)熔斷、限流騷操作