Seata 分佈式事務框架

本文首發於我的微信公衆號《andyqian》, 期待你的關注~

前言

上一篇文章《Seata 之 rm-datasource 源碼解讀》發出後。有不少同窗對 Seata 是什麼還不夠了解，今天咱們就起來認識一下它。

簡介

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

什麼是分佈式事務？

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

 

隨着互聯網應用的發展，單體應用架構已不足以應付。且呈現出諸多弊端，例如：多團隊開發效率不高，模塊之間強耦合，打包部署慢，等問題。後面你們採用了分而治之的方法，就有了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 中，一個典型的生命週期以下所示：

1. TM 要求 TC 生成一個全局事務，並由 TC 生成一個全局事務XID 返回。
2. XID 經過微服務調用鏈傳播。
3. RM 向 TC 註冊本地事務，將其註冊到 ID 爲 XID 的全局事務中。
4. TM 要求 TC 提交或回滾XID 對應的全局事務。
5. TC 驅動 XID 對應的全局事務對應的全部的分支事務提交或回滾。

圖片來自seata 博客

---

相關閱讀:

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

 

 掃碼關注，一塊兒進步

我的博客: http://www.andyqian.com