一、SEATA是什么？

Seata 是一款開(kāi)源的分布式事務(wù)解決方案，致力于提供高性能和簡(jiǎn)單易用的分布式事務(wù)服務(wù)。Seata 將為用戶提供了 AT、TCC、SAGA 和 XA 事務(wù)模式，為用戶打造一站式的分布式解決方案。

在繼續(xù)學(xué)習(xí)使用SEATA之前，對(duì)seata介紹中提到的分布式事務(wù)、AT、TCC、SAGA 和 XA 事務(wù)模式這些名詞有必要介紹一下。

1.什么是分布式事務(wù)？

首先說(shuō)下事務(wù)，事務(wù)是應(yīng)用程序中一系列嚴(yán)密的操作，所有操作必須成功完成，否則在每個(gè)操作中所作的所有更改都會(huì)被撤消。

事務(wù)應(yīng)該具有 4 個(gè)屬性：原子性、一致性、隔離性、持久性。這四個(gè)屬性通常稱為 ACID 特性。

事務(wù)更多指的是單機(jī)版、單數(shù)據(jù)庫(kù)的概念。分布式事務(wù)用于在分布式系統(tǒng)中保證不同節(jié)點(diǎn)之間的數(shù)據(jù)一致性。

漫畫: 什么是分布式事務(wù)?

2. XA規(guī)范

有了分布式事務(wù)的場(chǎng)景，就會(huì)有解決該問(wèn)題的方式規(guī)范，XA規(guī)范就是解決分布式事務(wù)的規(guī)范。分布式事務(wù)的實(shí)現(xiàn)方式有很多種，最具有代表性的是由Oracle Tuxedo系統(tǒng)提出的 XA分布式事務(wù)協(xié)議。XA協(xié)議包括兩階段提交（2PC）和三階段提交（3PC）兩種實(shí)現(xiàn)。

兩階段提交（2PC）

兩階段提交又稱2PC（two-phase commit protocol）,2pc是一個(gè)非常經(jīng)典的強(qiáng)一致、中心化的原子提交協(xié)議。這里所說(shuō)的中心化是指協(xié)議中有兩類節(jié)點(diǎn)：一個(gè)是中心化協(xié)調(diào)者節(jié)點(diǎn)（coordinator）和N個(gè)參與者節(jié)點(diǎn)（partcipant）。

準(zhǔn)備階段 　　　　事務(wù)協(xié)調(diào)者，向所有事務(wù)參與者發(fā)送事務(wù)內(nèi)容，詢問(wèn)是否可以提交事務(wù)，并等待參與者回復(fù)。 　　　　事務(wù)參與者收到事務(wù)內(nèi)容，開(kāi)始執(zhí)行事務(wù)操作，講 undo 和 redo 信息記入事務(wù)日志中（但此時(shí)并不提交事務(wù)）。 　　　　如果參與者執(zhí)行成功，給協(xié)調(diào)者回復(fù)yes,表示可以進(jìn)行事務(wù)提交。如果執(zhí)行失敗，給協(xié)調(diào)者回復(fù)no,表示不可提交。

XA一階段提交

提交階段 　　　　如果協(xié)調(diào)者收到了參與者的失敗信息或超時(shí)信息，直接給所有參與者發(fā)送回滾（rollback）信息進(jìn)行事務(wù)回滾，否則，發(fā)送提交（commit）信息。 　　　　參與者根據(jù)協(xié)調(diào)者的指令執(zhí)行提交或者回滾操作，釋放所有事務(wù)處理過(guò)程中使用的鎖資源。(注意：必須在最后階段釋放鎖資源) 。

[圖片上傳失敗…(image-a6b970-1618380177779)]

xa規(guī)范2pc異常提交階段

以下幾點(diǎn)是XA-兩階段提交協(xié)議中會(huì)遇到的一些問(wèn)題：

• 性能問(wèn)題

從流程上我們可以看得出，其最大缺點(diǎn)就在于它的執(zhí)行過(guò)程中間，節(jié)點(diǎn)都處于阻塞狀態(tài)。各個(gè)操作數(shù)據(jù)庫(kù)的節(jié)點(diǎn)此時(shí)都占用著數(shù)據(jù)庫(kù)資源，只有當(dāng)所有節(jié)點(diǎn)準(zhǔn)備完畢，事務(wù)協(xié)調(diào)者才會(huì)通知進(jìn)行全局提交，參與者進(jìn)行本地事務(wù)提交后才會(huì)釋放資源。這樣的過(guò)程會(huì)比較漫長(zhǎng)，對(duì)性能影響比較大。

• 協(xié)調(diào)者單點(diǎn)故障問(wèn)題

事務(wù)協(xié)調(diào)者是整個(gè)XA模型的核心，一旦事務(wù)協(xié)調(diào)者節(jié)點(diǎn)掛掉，會(huì)導(dǎo)致參與者收不到提交或回滾的通知，從而導(dǎo)致參與者節(jié)點(diǎn)始終處于事務(wù)無(wú)法完成的中間狀態(tài)。

• 丟失消息導(dǎo)致的數(shù)據(jù)不一致問(wèn)題

在第二個(gè)階段，如果發(fā)生局部網(wǎng)絡(luò)問(wèn)題，一部分事務(wù)參與者收到了提交消息，另一部分事務(wù)參與者沒(méi)收到提交消息，那么就會(huì)導(dǎo)致節(jié)點(diǎn)間數(shù)據(jù)的不一致問(wèn)題。

2PC 方案實(shí)現(xiàn)起來(lái)簡(jiǎn)單，基于上面提到的兩階段提交協(xié)議中會(huì)遇到的問(wèn)題，實(shí)際項(xiàng)目中使用的比較少。那么有沒(méi)有其他的方案來(lái)解決呢？

三階段提交（3PC）

三階段提交是在二階段提交上的改進(jìn)版本，其在兩階段提交的基礎(chǔ)上增加了 CanCommit階段，并加入了超時(shí)機(jī)制。同時(shí)在協(xié)調(diào)者和參與者中都引入超時(shí)機(jī)制。三階段將二階段的準(zhǔn)備階段拆分為2個(gè)階段，插入了一個(gè)preCommit階段，以此來(lái)處理原先二階段，參與者準(zhǔn)備后，參與者發(fā)生崩潰或錯(cuò)誤，導(dǎo)致參與者無(wú)法知曉是否提交或回滾的不確定狀態(tài)所引起的延時(shí)問(wèn)題。

階段 1：canCommit

• 協(xié)調(diào)者向所有參與者發(fā)出包含事務(wù)內(nèi)容的 canCommit 請(qǐng)求，詢問(wèn)是否可以提交事務(wù)，并等待所有參與者答復(fù)。

• 參與者收到 canCommit 請(qǐng)求后，如果認(rèn)為可以執(zhí)行事務(wù)操作，則反饋 yes 并進(jìn)入預(yù)備狀態(tài)，否則反饋 no。

xa規(guī)范3pc-canCommit

階段 2：preCommit

階段一中，如果所有的參與者都返回Yes的話，那么就會(huì)進(jìn)入PreCommit階段進(jìn)行事務(wù)預(yù)提交。此時(shí)分布式事務(wù)協(xié)調(diào)者會(huì)向所有的參與者節(jié)點(diǎn)發(fā)送PreCommit請(qǐng)求，參與者收到后開(kāi)始執(zhí)行事務(wù)操作，并將Undo和Redo信息記錄到事務(wù)日志中。參與者執(zhí)行完事務(wù)操作后（此時(shí)屬于未提交事務(wù)的狀態(tài)），就會(huì)向協(xié)調(diào)者反饋“Ack”表示我已經(jīng)準(zhǔn)備好提交了，并等待協(xié)調(diào)者的下一步指令。如果階段一中有任何一個(gè)參與者節(jié)點(diǎn)返回的結(jié)果是No響應(yīng)，或者協(xié)調(diào)者在等待參與者節(jié)點(diǎn)反饋的過(guò)程中因掛掉而超時(shí)（2PC中只有協(xié)調(diào)者可以超時(shí)，參與者沒(méi)有超時(shí)機(jī)制）。整個(gè)分布式事務(wù)就會(huì)中斷，協(xié)調(diào)者就會(huì)向所有的參與者發(fā)送“abort”請(qǐng)求。

xa規(guī)范3pc-preCommit

階段 3：do Commit

該階段進(jìn)行真正的事務(wù)提交，在階段二中如果所有的參與者節(jié)點(diǎn)都可以進(jìn)行PreCommit提交，那么協(xié)調(diào)者就會(huì)從“預(yù)提交狀態(tài)” 轉(zhuǎn)變?yōu)?“提交狀態(tài)”。然后向所有的參與者節(jié)點(diǎn)發(fā)送"doCommit"請(qǐng)求，參與者節(jié)點(diǎn)在收到提交請(qǐng)求后就會(huì)各自執(zhí)行事務(wù)提交操作，并向協(xié)調(diào)者節(jié)點(diǎn)反饋“Ack”消息，協(xié)調(diào)者收到所有參與者的Ack消息后完成事務(wù)。

xa規(guī)范3pc-doCommit

相比較2PC而言，3PC對(duì)于協(xié)調(diào)者（Coordinator）和參與者（Partcipant）都設(shè)置了超時(shí)時(shí)間，而2PC只有協(xié)調(diào)者才擁有超時(shí)機(jī)制。這解決了一個(gè)什么問(wèn)題呢？這個(gè)優(yōu)化點(diǎn)，主要是避免了參與者在長(zhǎng)時(shí)間無(wú)法與協(xié)調(diào)者節(jié)點(diǎn)通訊（協(xié)調(diào)者掛掉了）的情況下，無(wú)法釋放資源的問(wèn)題，因?yàn)閰⑴c者自身?yè)碛谐瑫r(shí)機(jī)制會(huì)在超時(shí)后，自動(dòng)進(jìn)行本地commit從而進(jìn)行釋放資源。而這種機(jī)制也側(cè)面降低了整個(gè)事務(wù)的阻塞時(shí)間和范圍。

另外，通過(guò)CanCommit、PreCommit、DoCommit三個(gè)階段的設(shè)計(jì)，相較于2PC而言，多設(shè)置了一個(gè)緩沖階段保證了在最后提交階段之前各參與節(jié)點(diǎn)的狀態(tài)是一致的。

以上就是3PC相對(duì)于2PC的一個(gè)提高（相對(duì)緩解了2PC中的前兩個(gè)問(wèn)題），但是3PC依然沒(méi)有完全解決數(shù)據(jù)不一致的問(wèn)題。假如在 DoCommit 過(guò)程，參與者A無(wú)法接收協(xié)調(diào)者的通信，那么參與者A會(huì)自動(dòng)提交，但是提交失敗了，其他參與者成功了，此時(shí)數(shù)據(jù)就會(huì)不一致。

3. AT(Auto Transaction)模式

AT 模式是一種無(wú)侵入的分布式事務(wù)解決方案。在 AT 模式下，用戶只需關(guān)注自己的“業(yè)務(wù) SQL”，用戶的 “業(yè)務(wù) SQL” 作為一階段，Seata 框架會(huì)自動(dòng)生成事務(wù)的二階段提交和回滾操作。

AT 模式如何做到對(duì)業(yè)務(wù)的無(wú)侵入

一階段

在一階段，Seata 會(huì)攔截“業(yè)務(wù) SQL”，首先解析 SQL 語(yǔ)義，找到“業(yè)務(wù) SQL”要更新的業(yè)務(wù)數(shù)據(jù)，在業(yè)務(wù)數(shù)據(jù)被更新前，將其保存成“before image”，然后執(zhí)行“業(yè)務(wù) SQL”更新業(yè)務(wù)數(shù)據(jù)，在業(yè)務(wù)數(shù)據(jù)更新之后，再將其保存成“after image”，最后生成行鎖。以上操作全部在一個(gè)數(shù)據(jù)庫(kù)事務(wù)內(nèi)完成，這樣保證了一階段操作的原子性。

以u(píng)pdate語(yǔ)句為例：

update user set name = ‘name_1’ where name = ‘name_0’

首先 Seata 的 JDBC數(shù)據(jù)源代理通過(guò)對(duì)業(yè)務(wù) SQL 解析，提取 SQL 的元數(shù)據(jù)，也就是得到 SQL 的類型（UPDATE），表（user），條件（where id= 1）等相關(guān)的信息。

提取表元數(shù)據(jù)：

select id,name from user where name = ‘name_0’

img

將查詢到的結(jié)果如上圖所示保存為“before image”，執(zhí)行“業(yè)務(wù) SQL”更新業(yè)務(wù)數(shù)據(jù)SQL。根據(jù)前鏡像數(shù)據(jù)主鍵查詢出后鏡像數(shù)據(jù)，查詢結(jié)果為：

select id,name from user where id = 1

把業(yè)務(wù)數(shù)據(jù)在更新前后的數(shù)據(jù)鏡像組織成回滾日志，將業(yè)務(wù)數(shù)據(jù)的更新和回滾日志在同一個(gè)本地事務(wù)中提交，分別插入到業(yè)務(wù)表和 UNDO_LOG 表中。

二階段提交

二階段如果是提交的話，因?yàn)椤皹I(yè)務(wù) SQL”在一階段已經(jīng)提交至數(shù)據(jù)庫(kù)， 所以 Seata 框架只需將一階段保存的快照數(shù)據(jù)和行鎖刪掉，完成數(shù)據(jù)清理即可。

二階段回滾

二階段如果是回滾的話，Seata 就需要回滾一階段已經(jīng)執(zhí)行的“業(yè)務(wù) SQL”，還原業(yè)務(wù)數(shù)據(jù)?；貪L方式便是用“before image”還原業(yè)務(wù)數(shù)據(jù)；但在還原前要首先要校驗(yàn)臟寫，對(duì)比“數(shù)據(jù)庫(kù)當(dāng)前業(yè)務(wù)數(shù)據(jù)”和 “after image”，如果兩份數(shù)據(jù)完全一致就說(shuō)明沒(méi)有臟寫，可以還原業(yè)務(wù)數(shù)據(jù)，如果不一致就說(shuō)明有臟寫，出現(xiàn)臟寫就需要轉(zhuǎn)人工處理。

總結(jié)

AT 模式的一階段、二階段提交和回滾均由 Seata 框架自動(dòng)生成，用戶只需編寫“業(yè)務(wù) SQL”，便能輕松接入分布式事務(wù)，AT 模式是一種對(duì)業(yè)務(wù)無(wú)任何侵入的分布式事務(wù)解決方案。但AT模式存在的不足就是 當(dāng)操作的數(shù)據(jù) 是共享型數(shù)據(jù)，會(huì)存在臟寫的問(wèn)題，所以如果是 用戶獨(dú)有數(shù)據(jù)可以使用AT模式。

4.TCC(Try、Confirm、Cancel)模式

TCC方案其實(shí)是兩階段提交的一種改進(jìn)。分成了Try、Confirm、Cancel三個(gè)操作。事務(wù)發(fā)起方在一階段執(zhí)行 Try 方式，在二階段提交執(zhí)行 Confirm 方法，二階段回滾執(zhí)行 Cancel 方法。@TwoPhaseBusinessAction是TCC服務(wù)參與者必須加的注解，指定服務(wù)名稱，提交方法commitMethod及回滾方法rollbackMethod，SecondAction同理

• Try部分完成業(yè)務(wù)的準(zhǔn)備工作

• confirm部分完成業(yè)務(wù)的提交

• cancel部分完成事務(wù)的回滾

  TCC 模式，不依賴于底層數(shù)據(jù)資源的事務(wù)支持：

• 一階段 prepare 行為：調(diào)用 自定義 的 prepare 邏輯。

• 二階段 commit 行為：調(diào)用 自定義 的 commit 邏輯。

• 二階段 rollback 行為：調(diào)用 自定義 的 rollback 邏輯。 所謂 TCC 模式，是指支持把 自定義 的分支事務(wù)納入到全局事務(wù)的管理中。簡(jiǎn)單點(diǎn)概括，SEATA的TCC模式就是手工的AT模式，它允許你自定義兩階段的處理邏輯而不依賴AT模式的undo_log。

• @LocalTCC 適用于SpringCloud+Feign模式下的TCC

• @TwoPhaseBusinessAction 注解try方法，其中name為當(dāng)前tcc方法的bean名稱，寫方法名便可（記得全局唯一），commitMethod指向提交方法，rollbackMethod指向事務(wù)回滾方法。指定好三個(gè)方法之后，seata會(huì)根據(jù)全局事務(wù)的成功或失敗，去幫我們自動(dòng)調(diào)用提交方法或者回滾方法。

• @BusinessActionContextParameter 注解可以將參數(shù)傳遞到二階段（commitMethod/rollbackMethod）的方法。

• BusinessActionContext 便是指TCC事務(wù)上下文

TCC實(shí)踐,總結(jié)以下注意事項(xiàng):

業(yè)務(wù)模型分2階段設(shè)計(jì) 并發(fā)控制 允許空回滾 防懸掛控制 冪等控制

用戶接入 TCC 模式，最重要的事情就是考慮如何將業(yè)務(wù)模型拆成 2 階段，實(shí)現(xiàn)成 TCC 的 3 個(gè)方法，并且保證 Try 成功 Confirm 一定能成功。相對(duì)于 AT 模式，TCC 模式對(duì)業(yè)務(wù)代碼有一定的侵入性，但是 TCC 模式無(wú) AT 模式的全局行鎖，TCC 性能會(huì)比 AT 模式高很多。

5.SAGA模式

SAGA簡(jiǎn)介

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)。

Saga模式示意圖

如圖：T1-T3都是正向的業(yè)務(wù)流程，都對(duì)應(yīng)著一個(gè)沖正逆向操作C1-C3。

分布式事務(wù)執(zhí)行過(guò)程中，依次執(zhí)行各參與者的正向操作，如果所有正向操作均執(zhí)行成功，那么分布式事務(wù)提交。如果任何一個(gè)正向操作執(zhí)行失敗，那么分布式事務(wù)會(huì)退回去執(zhí)行前面各參與者的逆向回滾操作，回滾已提交的參與者，使分布式事務(wù)回到初始狀態(tài)。

Saga 正向服務(wù)與補(bǔ)償服務(wù)也需要業(yè)務(wù)開(kāi)發(fā)者實(shí)現(xiàn)。因此是業(yè)務(wù)入侵的。

Saga 模式下分布式事務(wù)通常是由事件驅(qū)動(dòng)的，各個(gè)參與者之間是異步執(zhí)行的，Saga 模式是一種長(zhǎng)事務(wù)解決方案。

Saga 模式使用場(chǎng)景

Saga 模式適用于業(yè)務(wù)流程長(zhǎng)且需要保證事務(wù)最終一致性的業(yè)務(wù)系統(tǒng)，Saga 模式一階段就會(huì)提交本地事務(wù)，無(wú)鎖、長(zhǎng)流程情況下可以保證性能。

事務(wù)參與者可能是其它公司的服務(wù)或者是遺留系統(tǒng)的服務(wù)，無(wú)法進(jìn)行改造和提供 TCC 要求的接口，可以使用 Saga 模式。

Saga模式的優(yōu)勢(shì)與缺點(diǎn)

優(yōu)勢(shì)

• 一階段提交本地?cái)?shù)據(jù)庫(kù)事務(wù)，無(wú)鎖，高性能；

• 參與者可以采用事務(wù)驅(qū)動(dòng)異步執(zhí)行，高吞吐

• 補(bǔ)償服務(wù)即正向服務(wù)的“反向”，易于理解，易于實(shí)現(xiàn)；

缺點(diǎn)

Saga 模式由于一階段已經(jīng)提交本地?cái)?shù)據(jù)庫(kù)事務(wù)，且沒(méi)有進(jìn)行“預(yù)留”動(dòng)作，所以不能保證隔離性。后續(xù)會(huì)講到對(duì)于缺乏隔離性的應(yīng)對(duì)措施。

注意

與TCC實(shí)踐經(jīng)驗(yàn)相同的是，Saga 模式中，每個(gè)事務(wù)參與者的沖正、逆向操作，需要支持：

• 空補(bǔ)償：逆向操作早于正向操作時(shí)；

• 防懸掛控制：空補(bǔ)償后要拒絕正向操作

• 冪等

總結(jié) AT、TCC、Saga、XA 模式分析

四種分布式事務(wù)模式，分別在不同的時(shí)間被提出，每種模式都有它的適用場(chǎng)景：

• AT 模式是無(wú)侵入的分布式事務(wù)解決方案，適用于不希望對(duì)業(yè)務(wù)進(jìn)行改造的場(chǎng)景，幾乎0學(xué)習(xí)成本。

• TCC 模式是高性能分布式事務(wù)解決方案，適用于核心系統(tǒng)等對(duì)性能有很高要求的場(chǎng)景。

• Saga 模式是長(zhǎng)事務(wù)解決方案，適用于業(yè)務(wù)流程長(zhǎng)且需要保證事務(wù)最終一致性的業(yè)務(wù)系統(tǒng)，Saga 模式一階段就會(huì)提交本地事務(wù)，無(wú)鎖，長(zhǎng)流程情況下可以保證性能，多用于渠道層、集成層業(yè)務(wù)系統(tǒng)。事務(wù)參與者可能是其它公司的服務(wù)或者是遺留系統(tǒng)的服務(wù)，無(wú)法進(jìn)行改造和提供 TCC 要求的接口，也可以使用 Saga 模式。

• XA模式是分布式強(qiáng)一致性的解決方案，但性能低而使用較少。

二.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ù)提交或回滾。