fescar分散式事務的詳細介紹（圖文）-java教程-PHP中文網

這篇文章帶給大家的內容是關於fescar分散式事務的介紹（圖文），有一定的參考價值，有需要的朋友可以參考一下，希望對你有幫助。

1、fescar分散式交易（概覽）

1.1. 概述

Fescar 是阿里巴巴開源的分散式交易中介軟體，以高效率且對業務0 侵入的方式，解決微服務場景下所面臨的分散式事務問題。

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. 設計概念圖

fescar分散式事務的詳細介紹（圖文）

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

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

fescar分散式事務的詳細介紹（圖文）

XA 方案的RM 實際上是在
資料庫層 ，RM 本質上就是資料庫本身（透過提供支援XA 的驅動程式來供應用使用）。
而Fescar 的RM 是以二方包的形式作為中間件層
部署在應用程式這一邊的，不依賴與資料庫本身對協定的支持，當然也不需要資料庫支援XA 協定。這點對於微服務化的架構來說是非常重要的：應用層不需要為本地事務和分散式事務兩類不同場景來適配兩組不同的資料庫驅動。
這個設計，剝離了分散式事務方案對資料庫在
協定支援 上的要求

1.4.3 .兩階段提交

1.4.3.1. XA 的2PC 流程

XA 的2PC 流程

fescar分散式事務的詳細介紹（圖文）

##無論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 模式管理的非事務性資源也可以和支援事務的關係型資料庫資源一起，納入同一個分散式事務的管理中。