一、SEATA是什么？

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

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

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

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

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

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

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

2. XA規(guī)范

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

兩階段提交（2PC）

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

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

XA一階段提交

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

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

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

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

• 性能問題

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

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

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

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

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

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

三階段提交（3PC）

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

階段 1：canCommit

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

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

xa規(guī)范3pc-canCommit

階段 2：preCommit

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

xa規(guī)范3pc-preCommit

階段 3：do Commit

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

xa規(guī)范3pc-doCommit

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

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

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

3. AT(Auto Transaction)模式

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

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

一階段

在一階段，Seata 會攔截“業(yè)務(wù) SQL”，首先解析 SQL 語義，找到“業(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”，最后生成行鎖。以上操作全部在一個數(shù)據(jù)庫事務(wù)內(nèi)完成，這樣保證了一階段操作的原子性。

以update語句為例：

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

首先 Seata 的 JDBC數(shù)據(jù)源代理通過對業(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ù)的更新和回滾日志在同一個本地事務(wù)中提交，分別插入到業(yè)務(wù)表和 UNDO_LOG 表中。

二階段提交

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

二階段回滾

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

總結(jié)

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

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

TCC方案其實是兩階段提交的一種改進(jìn)。分成了Try、Confirm、Cancel三個操作。事務(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ù)的管理中。簡單點概括，SEATA的TCC模式就是手工的AT模式，它允許你自定義兩階段的處理邏輯而不依賴AT模式的undo_log。

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

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

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

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

TCC實踐,總結(jié)以下注意事項:

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

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

5.SAGA模式

SAGA簡介

Saga模式是SEATA提供的長事務(wù)解決方案，在Saga模式中，業(yè)務(wù)流程中每個參與者都提交本地事務(wù)，當(dāng)出現(xiàn)某一個參與者失敗則補償前面已經(jīng)成功的參與者，一階段正向服務(wù)和二階段補償服務(wù)都由業(yè)務(wù)開發(fā)實現(xiàn)。

Saga模式示意圖

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

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

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

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

Saga 模式使用場景

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

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

Saga模式的優(yōu)勢與缺點

優(yōu)勢

• 一階段提交本地數(shù)據(jù)庫事務(wù)，無鎖，高性能；

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

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

缺點

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

注意

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

• 空補償：逆向操作早于正向操作時；

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

• 冪等

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

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

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

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

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

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

二.SEATA術(shù)語

TC (Transaction Coordinator) - 事務(wù)協(xié)調(diào)者

維護(hù)全局和分支事務(wù)的狀態(tài)，驅(qū)動全局事務(wù)提交或回滾。

TM (Transaction Manager) - 事務(wù)管理器

定義全局事務(wù)的范圍：開始全局事務(wù)、提交或回滾全局事務(wù)。

RM (Resource Manager) - 資源管理器

管理分支事務(wù)處理的資源，與TC交談以注冊分支事務(wù)和報告分支事務(wù)的狀態(tài)，并驅(qū)動分支事務(wù)提交或回滾。