本文首發於個人微信公衆號《andyqian》， 期待你的關注~
前言
上一篇文章《Seata 之 rm-datasource 源碼解讀》發出後。有很多同學對 Seata 是什麼還不夠了解，今天我們就起來認識一下它。
簡介
Seata 是一款由阿里巴巴與螞蟻金服共同開源的分佈式事務框架。由最初的Fescar（Fast & Easy Commit And Rollback）框架更名而來。其設計初衷是：讓分佈式事務能夠像本地事務一樣簡單，高效。
什麼是分佈式事務？
在上面介紹中，提到了分佈式事務，它並不是一個新詞。但在介紹之前，我覺得有必要先回顧下。事務是我們熟悉的，它有四大特性，分別是：原子性，一致性，隔離性，持久性。由底層數據庫提供支持，如MySQL中的 Innodb 存儲引擎。在單體應用中，甚至是在單例數據庫應用中，使用數據庫本身提供的事務就能解決大部分：數據不一致等一系列問題。架構如下圖所示：
隨着互聯網應用的發展，單體應用架構已不足以應付。且呈現出諸多弊端，例如：多團隊開發效率不高，模塊之間強耦合，打包部署慢，等問題。後面大家採用了分而治之的方法，就有了SOA架構，再到現在盛行的微服務架構。
當然，當單一數據庫實例不足以支撐現有的業務時，就出現了分庫分表。通常的做法是：將不同的業務分爲不同的數據庫實例。也就有了如下的分佈圖：
在這樣的架構下。原本數據庫提供的本地事務已經相形見絀，並提出了一個新的挑戰。在分佈式架構下，如何保證數據的一致性，原子性等等 ？
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 對應的全局事務對應的所有的分支事務提交或回滾。
相關閱讀:
《Dubbo 線程池源碼解析》
《你所不知道的 BigDecimal》
《ThreadPoolExecutor 原理解析》
《Java線程池ThreadPoolExecutor》
