fescar分布式事務是什么

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

1. Transaction Coordinator (TC)： 事務協調器，維護全局事務的運行狀態，負責協調并驅動全局事務的提交或回滾。

2. Transaction Manager (TM)： 控制全局事務的邊界，負責開啟一個全局事務，并最終發起全局提交或全局回滾的決議。

3. Resource Manager (RM)： 控制分支事務，負責分支注冊、狀態匯報，并接收事務協調器的指令，驅動分支（本地）事務的提交和回滾。

1.4.2. 與 XA 的差別在什么地方？

1. XA 方案的 RM 實際上是在數據庫層 ，RM 本質上就是數據庫自身（通過提供支持 XA 的驅動程序來供應用使用）。

2. 而 Fescar 的 RM 是以二方包的形式作為中間件層部署在應用程序這一側的，不依賴與數據庫本身對協議的支持，當然也不需要數據庫支持 XA 協議。這點對于微服務化的架構來說是非常重要的：應用層不需要為本地事務和分布式事務兩類不同場景來適配兩套不同的數據庫驅動。

3. 這個設計，剝離了分布式事務方案對數據庫在 協議支持 上的要求

1.4.3. 兩階段提交

1.4.3.1. XA 的 2PC 過程

1. XA 的 2PC 過程
   

2. 無論 Phase2 的決議是 commit 還是 rollback，事務性資源的鎖都要保持到 Phase2 完成才釋放。
   設想一個正常運行的業務，大概率是 90% 以上的事務最終應該是成功提交的，我們是否可以在 Phase1 就將本地事務提交呢？這樣 90% 以上的情況下，可以省去 Phase2 持鎖的時間，整體提高效率。

1.4.3.2. fescar的 2PC 過程

1. 分支事務中數據的 本地鎖 由本地事務管理，在分支事務 Phase1 結束時釋放。

2. 同時，隨著本地事務結束，連接 也得以釋放。

3. 分支事務中數據的 全局鎖 在事務協調器側管理，在決議 Phase2 全局提交時，全局鎖馬上可以釋放。只有在決議全局回滾的情況下，全局鎖 才被持有至分支的 Phase2 結束。

4. 這個設計，極大地減少了分支事務對資源（數據和連接）的鎖定時間，給整體并發和吞吐的提升提供了基礎。

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

1. 首先，應用需要使用 Fescar 的 JDBC 數據源代理，也就是 Fescar 的 RM
   

2. Fescar 的 JDBC 數據源代理通過對業務 SQL 的解析，把業務數據在更新前后的數據鏡像組織成回滾日志，利用 本地事務 的 ACID 特性，將業務數據的更新和回滾日志的寫入在同一個 本地事務 中提交。

3. 這樣，可以保證：任何提交的業務數據的更新一定有相應的回滾日志存在
   

4. 如果決議是全局提交，此時分支事務此時已經完成提交，不需要同步協調處理（只需要異步清理回滾日志），Phase2 可以非常快速地完成。

5. 如果決議是全局回滾，RM 收到協調器發來的回滾請求，通過 XID 和 Branch ID 找到相應的回滾日志記錄，通過回滾記錄生成反向的更新 SQL 并執行，以完成分支的回滾。

1.4.5. 事務傳播機制

1. XID 是一個全局事務的唯一標識，事務傳播機制要做的就是把 XID 在服務調用鏈路中傳遞下去，并綁定到服務的事務上下文中，這樣，服務鏈路中的數據庫更新操作，就都會向該 XID 代表的全局事務注冊分支，納入同一個全局事務的管轄。

2. 基于這個機制，Fescar 是可以支持任何微服務 RPC 框架的。只要在特定框架中找到可以透明傳播 XID 的機制即可，比如，Dubbo 的 Filter + RpcContext。

1.4.6. 分支的基本行為模式

作為全局事務一部分的分支事務，除本身的業務邏輯外，都包含 4 個與協調器交互的行為：

1. 分支注冊： 在分支事務的數據操作進行之前，需要向協調器注冊，把即將進行的分支事務數據操作，納入一個已經開啟的全局事務的管理中去，在分支注冊成功后，才可以進行數據操作。

2. 狀態上報： 在分支事務的數據操作完成后，需要向事務協調器上報其執行結果。

3. 分支提交：響應協調器發出的分支事務提交的請求，完成分支提交。

4. 分支回滾：響應協調器發出的分支事務回滾的請求，完成分支回滾。
   

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

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

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

1. 業務邏輯需要被分解為 Prepare/Commit/Rollback 3 部分，形成一個 MT 分支，加入全局事務。
   

1.4.9. 混合模式

因為 AT 和 MT 模式的分支從根本上行為模式是一致的，所以可以完全兼容，即，一個全局事務中，可以同時存在 AT 和 MT 的分支。這樣就可以達到全面覆蓋業務場景的目的：AT 模式可以支持的，使用 AT 模式；AT 模式暫時支持不了的，用 MT 模式來替代。另外，自然的，MT 模式管理的非事務性資源也可以和支持事務的關系型數據庫資源一起，納入同一個分布式事務的管理中。

1.5. 初步的版本規劃

v0.1.0

• 微服務框架支持: Dubbo

• 數據庫支持: MySQL

• 基于 Spring AOP 的 Annotation

• 事務協調器: 單機版本

v0.5.x

• 微服務框架支持: Spring Cloud

• MT 模式

• 支持 TCC 模式事務的適配

• 動態配置和服務發現

• 事務協調器: 高可用集群版本

v0.8.x

• Metrics

• 控制臺: 監控/部署/升級/擴縮容

v1.0.0

• General Availability: 生產環境適用

v1.5.x

• 數據庫支持: Oracle/PostgreSQL/OceanBase

• 不依賴 Spring AOP 的 Annotation

• 熱點數據的優化處理機制

• RocketMQ 事務消息納入全局事務管理

• NoSQL 納入全局事務管理的適配機制

• 支持 HBase

• 支持 Redis

v2.0.0

• 支持 XA
  當然，項目迭代演進的過程，我們最重視的是社區的聲音，路線圖會和社區充分交流及時進行調整。

1.6. 總結

??看完概覽，我一口鮮血噴出來，明明說好的支持任何微服務RPC框架，我現在要在適合SpringCloud的分布式事務解決方案中挑選個，你告訴我預計下下下下個版本會集成SpringCloud，路過的大神，推薦個吧

1.7. github開源地址

https://github.com/alibaba/fescar/

感謝各位的閱讀！看完上述內容，你們對fescar分布式事務是什么大概了解了嗎？希望文章內容對大家有所幫助。如果想了解更多相關文章內容，歡迎關注億速云行業資訊頻道。