> 單個掉隊，導致集體被動擺爛；

# 一、業務背景

在分散式架構中，事務管理是個無法避開的複雜問題，雖然有多種解決方案，但是需要根據業務去選擇合適的；

從個人最近幾年的實踐經驗來看，Seata元件的AT模式比較常用，本文從實際的案例出發，來深入分析該模式的原理；

![](http://img.blog.itpub.net/blog/2022/12/01/854cbaf613125302.png?x-oss-process=style/bb)

首先建立一個全域性事務管理的介面，這裡是在Facade服務中開啟全域性事務；

請求經過三個微服務，並且各個服務都進行資料來源的操作，然後模擬鏈路成功和異常的情況，來分析不同狀態的邏輯實現；

# 二、Seata架構

## 1、核心元件

![](http://img.blog.itpub.net/blog/2022/12/01/c78ceb4e06bb7f53.png?x-oss-process=style/bb)

**三大元件**

- TC：事務協調者

即Transaction Coordinator，維護全域性和分支事務的狀態，驅動全域性事務提交或回滾。

- TM：事務管理器

即Transaction Manager，定義全域性事務的範圍，開始事務、提交事務，回滾事務。

- RM：資源管理器

即Resource Manager，管理分支事務處理的資源，向TC註冊分支事務，報告分支事務的狀態，驅動分支事務提交或回滾。

**基礎互動**

TC是需要獨立部署的服務，TM和RM是整合在服務中，三大元件相互協作，共同完成分佈事務的管理；

## 2、AT模式

**事務模型**

AT是Seata預設的模式，需要基於支援本地ACID事務的關係型資料庫；Java應用，透過JDBC訪問資料庫；基於案例流程，先分析AT的事務模型；

![](http://img.blog.itpub.net/blog/2022/12/01/d36e97e1c5e8ae90.png?x-oss-process=style/bb)

2.1 TM負責定義全域性事務的邊界，向TC申請，開啟一個全域性事務；

2.2 全域性事務建立成功後，生成全域性唯一的XID；

2.3 XID會在微服務請求鏈路上下文中傳播；

2.4 RM向TC註冊分支事務，並歸屬到XID對應的全域性事務進行排程；

2.5 TM向TC發起相應XID的全域性事務提交或回滾決議；

2.6 TC完成對XID管理的全部分支事務提交或回滾的排程；

**核心機制**

![](http://img.blog.itpub.net/blog/2022/12/01/3defb239621feee8.png?x-oss-process=style/bb)

執行階段：每個微服務的請求完成後，基於本地資料庫的事務能力，保證業務資料和回滾日誌在同一個本地事務中提交，快速釋放連線和對資源的鎖定；

完成階段：全域性提交時分支事務已經完成提交，會清理回滾日誌，快速結束流程；全域性回滾基於XID和BranchID查詢回滾日誌，完成資料回滾；

**資料來源代理**

![](http://img.blog.itpub.net/blog/2022/12/01/2cb72db4314a3e31.png?x-oss-process=style/bb)

在AT模式中，應用需要使用Seata元件中的JDBC代理資料來源DataSourceProxy，實現對真正目標資料來源的代理訪問；

# 三、案例分析

## 1、流程分析

案例的簡單描述

![](http://img.blog.itpub.net/blog/2022/12/01/0c7ad6180dfa4052.png?x-oss-process=style/bb)

在案例中涉及三個服務，Facade服務開啟全域性事務，然後分別請求Account和Quartz服務的更新介面，透過Quartz介面是否拋異常來除錯AT模式的原理；

![](http://img.blog.itpub.net/blog/2022/12/01/8dcc82abd9287771.png?x-oss-process=style/bb)

從實際的請求執行來說，絕大多數的請求都是可以執行成功的，而AT模式的非同步化提交極大限度的顧及全域性事務的效率問題，少數失敗的情況也可以透過回滾日誌進行反向補償；

## 2、寫隔離

上述流程分析AT模式的原子性，即多個分支事務要麼都成功要麼都失敗，接下來分析多個事務中的全域性鎖隔離機制，先看寫隔離，假設TX1先開始；

![](http://img.blog.itpub.net/blog/2022/12/01/1b4200691ba20b98.png?x-oss-process=style/bb)

**TX1邏輯**

- TX1開始本地事務，拿到本地鎖，然後執行更新操作；
- TX1本地事務提交前，需要先獲取全域性鎖，否則無法提交；
- TX1獲取全域性鎖並提交，釋放本地鎖，但未釋放全域性鎖；

**TX2邏輯**

- TX2此時開始本地事務，拿到本地鎖；
- TX2執行本地事務提交前，嘗試獲取全域性鎖；
- 由於全域性鎖被TX1持有，TX2會重試等待全域性鎖；

**假設TX1全域性提交**

- TX1如果全域性事務提交，會釋放全域性鎖；
- TX2獲取全域性鎖成功，執行本地事務提交；

**假設TX1全域性回滾**

- TX1如果全域性事務回滾，要重新獲取資料的本地鎖，進行回滾的補償動作；
- TX2如果仍在等待全域性鎖，並且還持有本地鎖，TX1事務回滾失敗，會不斷的重試；
- 當TX2等待全域性鎖超時，會放棄全域性鎖並回滾本地事務，釋放本地鎖；
- TX1最終獲取資料的本地鎖，完成回滾動作；

在該過程中，TX1在結束前一直持有全域性鎖，TX2獲取不到全域性鎖無法對相同的資料執行更新動作，所以避免了髒寫的問題；

## 3、讀隔離

在資料庫本地隔離級別為讀已提交或以上的基礎上，Seata的AT模式預設全域性隔離級別是讀未提交；如果需要全域性的讀已提交，可以透過`SELECT FOR UPDATE`語句的代理；

![](http://img.blog.itpub.net/blog/2022/12/01/37e4b6ecc254d6c7.png?x-oss-process=style/bb)

該語句的執行也需要獲取全域性鎖，如果全域性鎖被TX1持有，TX2會釋放本地鎖，查詢會被阻塞並進行重試，拿到全域性鎖讀取成功後返回；

# 四、對比XA模式

XA是一個分散式事務分段提交協議；事務管理器即TM：作為全域性事務的排程者，負責整個事務中本地資源的提交和回滾；本地資源管理器即RM：大部分關係型資料庫都實現了XA介面；

![](http://img.blog.itpub.net/blog/2022/12/01/dd10476097e34fa8.png?x-oss-process=style/bb)

TM先向所有的參與事務的RM傳送確認請求，根據確認的結果，判斷是呼叫RM的commit提交還是rollback回滾；

XA具有強一致性，在2段提交的過程中，會持有資源的鎖，如果是在交易下單等複雜鏈路中，並且併發量很高，會存在長事務風險，XA無法滿足該類高併發的場景；

而在Seata的AT模式中，在服務執行完成後，直接進行RM提交和資源釋放，提供了對CAP理論相對平衡的解決方案，並且沒有侵入業務工程；

# 五、參考原始碼

```
應用倉庫：
https://gitee.com/cicadasmile/butte-flyer-parent

元件封裝：
https://gitee.com/cicadasmile/butte-frame-parent
```

深入淺出Seata的AT模式

相關文章