本文首發于個人微信公眾號《andyqian》, 期待你的關注~

前言
上一篇文章《Seata 之 rm-datasource 源碼解讀》發出后。有很多同學對 Seata 是什么還不夠了解，今天我們就起來認識一下它。

簡介

Seata 是一款由阿里巴巴與螞蟻金服共同開源的分布式事務框架。由最初的Fescar（Fast & Easy Commit And Rollback）框架更名而來。其設計初衷是：讓分布式事務能夠像本地事務一樣簡單，高效。

什么是分布式事務？

在上面介紹中，提到了分布式事務，它并不是一個新詞。但在介紹之前，我覺得有必要先回顧下。事務是我們熟悉的，它有四大特性，分別是：原子性，一致性，隔離性，持久性。由底層數據庫提供支持，如MySQL中的 Innodb 存儲引擎。在單體應用中，甚至是在單例數據庫應用中，使用數據庫本身提供的事務就能解決大部分：數據不一致等一系列問題。架構如下圖所示：

圖片來自 seata 博客

隨著互聯網應用的發展，單體應用架構已不足以應付。且呈現出諸多弊端，例如：多團隊開發效率不高，模塊之間強耦合，打包部署慢，等問題。后面大家采用了分而治之的方法，就有了SOA架構，再到現在盛行的微服務架構。

當然，當單一數據庫實例不足以支撐現有的業務時，就出現了分庫分表。通常的做法是：將不同的業務分為不同的數據庫實例。也就有了如下的分布圖：

圖片來自于 seata 博客

在這樣的架構下。原本數據庫提供的本地事務已經相形見絀，并提出了一個新的挑戰。在分布式架構下，如何保證數據的一致性，原子性等等 ？

CAP 理論
在單體應用中，有數據庫本身提供的事務保駕護航，我們可以更加關注的編寫業務代碼。在分布式應用中，在面對各個節點狀態同步時，提出了一個新的理論，它就是CAP 理論。
CAP 理論最早由：加州大學的計算機科學家 Eric Brewer 在 1998 年提出，分布式系統有三個指標：

• Consistency (一致性)
• Availability (可用性)
• Partition tolerance (分區容忍性)

Eric Brewer 說，這三個指標不可能同時做到。
其架構圖如下所示：

圖片來自 阮一峰 博客

Seata 的原理

在 Seata中，是如何定義分布式事務的呢？從上圖改造而來，如下圖所示：

圖片來自 seata 博客

在 Seata 中，將 Storage 服務看成一個本地事務，Business 服務看成一個本地事務，將 Order 服務看成一個本地事務，將 Account 服務看成一個本地事務，其構成了一個 Distributed Transaction，由 TC 統一協調。在 Seata 中稱之為 “Global Transaction”，如下所示：

圖片來自 seata 博客

在 Seata 中有三個基礎組件：

• Transaction Coordinator(TC)(協調者)：維護全局和分支事務的狀態，驅動全局提交或回滾。
• Transaction Manager(TM)(事務管理)：定義全局事務的范圍，開啟全局事務，提交 或 回滾一個全局事務。
• Resource Manager(RM)(資源管理)：管理分支事務資源。與 TC 通訊并報告分支事務狀態，管理本地事務的提交與回滾。

Seata 的生命周期

在 Seata 中，一個典型的生命周期如下所示：

TM 要求 TC 生成一個全局事務，并由 TC 生成一個全局事務XID 返回。

XID 通過微服務調用鏈傳播。

RM 向 TC 注冊本地事務，將其注冊到 ID 為 XID 的全局事務中。

TM 要求 TC 提交或回滾XID 對應的全局事務。

TC 驅動 XID 對應的全局事務對應的所有的分支事務提交或回滾。

圖片來自seata 博客

---

相關閱讀:

《Dubbo 線程池源碼解析》
《你所不知道的 BigDecimal》
《ThreadPoolExecutor 原理解析》
《Java線程池ThreadPoolExecutor》

---

總結

以上是生活随笔為你收集整理的seata xid是什么_Seata 分布式事务框架的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。