目錄

一、XA模式

【1】兩階段提交

【2】Seata的XA模型

【3】優缺點

【4】實現XA模式

二、AT模式

【1】Seata的AT模型

【2】AT與XA的區別

【3】臟寫問題

【4】優缺點

【5】實現AT模式

---

一、XA模式

????????XA 規范 是 X/Open 組織定義的分布式事務處理（DTP，Distributed Transaction Processing）標準， XA 規范 描述了全局的TM與局部的RM之間的接口，幾乎所有主流的數據庫都對 XA規范提供了支持。

---

【1】兩階段提交

XA是規范，目前主流數據庫都實現了這種規范，實現的原理都是基于兩階段提交。

正常情況：

異常情況：

?階段：

• 事務協調者通知每個事物參與者執行本地事務
• 本地事務執行完成后報告事務執行狀態給事務協調者，此時事務不提交，繼續持有數據庫鎖

?階段：

• 事務協調者基于?階段的報告來判斷下?步操作
  • 如果?階段都成功，則通知所有事務參與者，提交事務
  • 如果?階段任意?個參與者失敗，則通知所有事務參與者回滾事務

---

【2】Seata的XA模型

RM?階段的工作：

• 注冊分支事務到TC
• 執行分支業務sql但不提交
• 報告執行狀態到TC

TC?階段的工作：

• TC檢測各分支事務執行狀態
• 如果都成功，通知所有RM提交事務
• 如果有失敗，通知所有RM回滾事務

RM?階段的工作：

• 接收TC指令，提交或回滾事務

---

【3】優缺點

XA模式的優點是什么？

• 事務的強?致性，滿足ACID原則。
• 常用數據庫都支持，實現簡單，并且沒有代碼侵?

XA模式的缺點是什么？

• 因為?階段需要鎖定數據庫資源，等待?階段結束才釋放，性能較差
• 依賴關系型數據庫實現事務

---

【4】實現XA模式

Seata的starter已經完成了XA模式的自動裝配，實現非常簡單，步驟如下：

1）修改application.yml文件（每個參與事務的微服務），開啟XA模式：

seata:data-source-proxy-mode: XA

2）給發起全局事務的入口方法添加@GlobalTransactional注解:

本例中是OrderServiceImpl中的create方法.

3）重啟服務并測試

重啟order-service，再次測試，發現無論怎樣，微服務都能成功回滾。

---

二、AT模式

【1】Seata的AT模型

基本流程圖：

階段?RM的工作：

• 注冊分支事務

• 記錄undo-log（數據快照）

• 執行業務sql并提交

• 報告事務狀態

階段?提交時RM的工作：

• 刪除undo-log即可

階段?回滾時RM的工作：

• 根據undo-log恢復數據到更新前

---

【2】AT與XA的區別

簡述AT模式與XA模式最大的區別是什么？

• XA模式?階段不提交事務，鎖定資源；AT模式?階段直接提交，不鎖定資源。

• XA模式依賴數據庫機制實現回滾；AT模式利用數據快照實現數據回滾。

• XA模式強?致；AT模式最終?致

---

【3】臟寫問題

在多線程并發訪問AT模式的分布式事務時，有可能出現臟寫問題，如圖：

????????解決思路就是引入了全局鎖的概念在釋放DB鎖之前，先拿到全局鎖，避免同?時刻有另外?個事務來操作當前數據。

---

【4】優缺點

AT模式的優點：

• ?階段完成直接提交事務，釋放數據庫資源，性能比較好
• 利用全局鎖實現讀寫隔離
• 沒有代碼侵?，框架自動完成回滾和提交

AT模式的缺點：

• 兩階段之間屬于軟狀態，屬于最終?致
• 框架的快照功能會影響性能，但比XA模式要好很多

---

【5】實現AT模式

????????AT模式中的快照生成、回滾等動作都是由框架自動完成，沒有任何代碼侵入，因此實現非常簡單。 只不過，AT模式需要?個表來記錄全局鎖、另?張表來記錄數據快照undo_log。

1）導入數據庫表，記錄全局鎖

運行seata-at.sql，其中lock_table導入到TC服務關聯的數據庫，undo_log表導?到微服務關聯的數據庫：

2）修改application.yml文件，將事務模式修改為AT模式即可：

seata:data-source-proxy-mode: AT # 默認就是AT

3）重啟服務并測試

---

????????感謝你花時間讀到這里～ 如果你覺得這篇內容對你有幫助，不妨點個贊讓更多人看到；如果有任何想法、疑問，或者想分享你的相關經歷，歡迎在評論區留言交流，你的每一條互動對我來說都很珍貴～ 我們下次再見啦！😊😊