fescar分佈式事務（概覽）

時間 2020-05-19

標籤 fescar 分佈式事務概覽欄目系統架構简体版

原文原文鏈接

1. fescar分佈式事務（概覽）

1.1. 概述

Fescar 是阿里巴巴開源的分佈式事務中間件，以高效而且對業務0 侵入 的方式，解決 微服務 場景下面臨的分佈式事務問題。git

1.2. Fescar 的發展歷程

2014 年，阿里中間件團隊發佈 TXC（Taobao Transaction Constructor），爲集團內應用提供分佈式事務服務。
2016 年，TXC 通過產品化改造，以 GTS（Global Transaction Service） 的身份登錄阿里雲，成爲當時業界惟一一款雲上分佈式事務產品 ，在阿雲裏的公有云、專有云解決方案中，開始服務於衆多外部客戶。
2019 年起，基於 TXC 和 GTS 的技術積累，阿里中間件團隊發起了開源項目 Fescar（Fast & EaSy Commit And Rollback, FESCAR），和社區一塊兒建設這個分佈式事務解決方案。

1.3. 設計初衷

對業務無侵入
高性能

1.4. 原理和設計

1.4.1. 設計概念圖

Transaction Coordinator (TC)： 事務協調器，維護全局事務的運行狀態，負責協調並驅動全局事務的提交或回滾。
Transaction Manager (TM)： 控制全局事務的邊界，負責開啓一個全局事務，並最終發起全局提交或全局回滾的決議。
Resource Manager (RM)： 控制分支事務，負責分支註冊、狀態彙報，並接收事務協調器的指令，驅動分支（本地）事務的提交和回滾。

1.4.2. 與 XA 的差異在什麼地方？

XA 方案的 RM 其實是在數據庫層 ，RM 本質上就是數據庫自身（經過提供支持 XA 的驅動程序來供應用使用）。
而 Fescar 的 RM 是以二方包的形式做爲中間件層部署在應用程序這一側的，不依賴與數據庫自己對協議的支持，固然也不須要數據庫支持 XA 協議。這點對於微服務化的架構來講是很是重要的：應用層不須要爲本地事務和分佈式事務兩類不一樣場景來適配兩套不一樣的數據庫驅動。
這個設計，剝離了分佈式事務方案對數據庫在 協議支持 上的要求

1.4.3. 兩階段提交

1.4.3.1. XA 的 2PC 過程

XA 的 2PC 過程 github
不管 Phase2 的決議是 commit 仍是 rollback，事務性資源的鎖都要保持到 Phase2 完成才釋放。設想一個正常運行的業務，大機率是 90% 以上的事務最終應該是成功提交的，咱們是否能夠在 Phase1 就將本地事務提交呢？這樣 90% 以上的狀況下，能夠省去 Phase2 持鎖的時間，總體提升效率。數據庫

1.4.3.2. fescar的 2PC 過程

分支事務中數據的 本地鎖 由本地事務管理，在分支事務 Phase1 結束時釋放。
同時，隨着本地事務結束，鏈接也得以釋放。
分支事務中數據的 全局鎖 在事務協調器側管理，在決議 Phase2 全局提交時，全局鎖立刻能夠釋放。只有在決議全局回滾的狀況下，全局鎖 才被持有至分支的 Phase2 結束。
這個設計，極大地減小了分支事務對資源（數據和鏈接）的鎖定時間，給總體併發和吞吐的提高提供了基礎。

1.4.4. 分支事務如何提交和回滾？（重點）

首先，應用須要使用 Fescar 的 JDBC 數據源代理，也就是 Fescar 的 RM 架構
Fescar 的 JDBC 數據源代理經過對業務 SQL 的解析，把業務數據在更新先後的數據鏡像組織成回滾日誌，利用 本地事務 的 ACID 特性，將業務數據的更新和回滾日誌的寫入在同一個本地事務中提交。併發
這樣，能夠保證：任何提交的業務數據的更新必定有相應的回滾日誌存在框架
若是決議是全局提交，此時分支事務此時已經完成提交，不須要同步協調處理（只須要異步清理回滾日誌），Phase2 能夠很是快速地完成。異步
若是決議是全局回滾，RM 收到協調器發來的回滾請求，經過 XID 和 Branch ID 找到相應的回滾日誌記錄，經過回滾記錄生成反向的更新 SQL 並執行，以完成分支的回滾。分佈式

1.4.5. 事務傳播機制

XID 是一個全局事務的惟一標識，事務傳播機制要作的就是把 XID 在服務調用鏈路中傳遞下去，並綁定到服務的事務上下文中，這樣，服務鏈路中的數據庫更新操做，就都會向該 XID 表明的全局事務註冊分支，歸入同一個全局事務的管轄。
基於這個機制，Fescar 是能夠支持任何微服務 RPC 框架的。只要在特定框架中找到能夠透明傳播 XID 的機制便可，好比，Dubbo 的 Filter + RpcContext。

1.4.6. 分支的基本行爲模式

做爲全局事務一部分的分支事務，除自己的業務邏輯外，都包含 4 個與協調器交互的行爲：微服務

分支註冊：在分支事務的數據操做進行以前，須要向協調器註冊，把即將進行的分支事務數據操做，歸入一個已經開啓的全局事務的管理中去，在分支註冊成功後，才能夠進行數據操做。
狀態上報：在分支事務的數據操做完成後，須要向事務協調器上報其執行結果。
分支提交：響應協調器發出的分支事務提交的請求，完成分支提交。
分支回滾：響應協調器發出的分支事務回滾的請求，完成分支回滾。

1.4.7. AT 模式分支的行爲模式

業務邏輯不須要關注事務機制，分支與全局事務的交互過程自動進行

1.4.8. MT 模式分支的行爲模式

業務邏輯須要被分解爲 Prepare/Commit/Rollback 3 部分，造成一個 MT 分支，加入全局事務。

1.4.9. 混合模式

由於 AT 和 MT 模式的分支從根本上行爲模式是一致的，因此能夠徹底兼容，即，一個全局事務中，能夠同時存在 AT 和 MT 的分支。這樣就能夠達到全面覆蓋業務場景的目的：AT 模式能夠支持的，使用 AT 模式；AT 模式暫時支持不了的，用 MT 模式來替代。另外，天然的，MT 模式管理的非事務性資源也能夠和支持事務的關係型數據庫資源一塊兒，歸入同一個分佈式事務的管理中。性能