關於開源分佈式事務中間件Fescar，咱們總結了開發者關心的13個問題

開源分佈式事務中間件 Fescar 自1月10日上線v0.1版本以來，受到了開發者們的極大關注（watch299，star3604，fork799，社區討論的issue79，數據統計於1月23日10:12），可見，天下苦分佈式事務久矣。

爲此，咱們收集了你們在社區（Github）和社羣（釘釘羣&微信羣）關注的核心問題，總結以下，並給出回覆。

Fescar 的發展經歷了哪些歷程？和阿里雲全局事務服務GTS之間是什麼關係？

Q1：Fescar 的發展經歷了哪些歷程？和阿里雲全局事務服務GTS之間是什麼關係？

A1：阿里巴巴是國內最先一批進行應用分佈式（微服務化）改造的企業，因此很早就遇到微服務架構下的分佈式事務問題。

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

TXC/GTS/Fescar一脈相承，爲解決微服務架構下的分佈式事務問題交出了一份不同凡響的答卷。

Fescar 有哪些適用場景？

Q2：Fescar 有哪些適用場景？

A2：Fescar 的願景是讓分佈式事務的使用像如今本地事務的使用同樣簡單、高效，最終的目標是但願能夠適用於全部的分佈式事務場景。目前，核心的 AT 模式適用於構建於支持本地 ACID 事務的關係型數據庫。非關係型數據庫類資源的管理，經過 MT 模式來支持。AT 模式與 MT 模式徹底兼容，因此能夠在同一個分佈式事務中，同時管理兩類資源。

目前有已經有一些其餘的分佈式事務開源方案，Fescar 和他們之間有哪些區別？和JTA支持分佈式事務有哪些區別？

Q3：目前有已經有一些其餘的分佈式事務開源方案，Fescar 和他們之間有哪些區別？和JTA支持分佈式事務有哪些區別？

A3：既有的分佈式事務解決方案按照對業務侵入性分爲兩類，即：對業務無侵入的和對業務有侵入的。

• 業務無侵入的方案 既有的主流分佈式事務解決方案中，對業務無侵入的只有基於 XA 的方案（注：問題中提到的 JTA 是XA 方案的 Java 版本），但應用XA 方案存在 3 個方面的問題：
  1. 要求數據庫提供對 XA 的支持。若是遇到不支持 XA（或支持得很差，好比 MySQL 5.7 之前的版本）的數據庫，則不能使用。
  2. 受協議自己的約束，事務資源（數據記錄、數據庫鏈接）的鎖定週期長。長週期的資源鎖定從業務層面來看，每每是沒必要要的，而由於事務資源的管理器是數據庫自己，應用層沒法插手。這樣造成的局面就是，基於 XA 的應用每每性能會比較差，並且很難優化。
  3. 已經落地的基於 XA 的分佈式解決方案，都依託於重量級的應用服務器（Tuxedo/WebLogic/WebSphere 等)，這是不適用於微服務架構的。
• 侵入業務的方案 實際上，最初分佈式事務只有 XA 這個惟一方案。XA 是完備的，但在實踐過程當中，因爲種種緣由（包含但不限於上面提到的3 點）每每不得不放棄，轉而從業務層面着手來解決分佈式事務問題。好比：
• 基於可靠消息的最終一致性方案
• TCC
• Saga

都屬於這一類。這些方案的具體機制在這裏不作展開，網上這方面的論述文章很是多。總之，這些方案都要求在應用的業務層面把分佈式事務技術約束考慮到設計中，一般每個服務都須要設計實現正向和反向的冪等接口。這樣的設計約束，每每會致使很高的研發和維護成本。

不能否認，侵入業務的分佈式事務方案都通過大量實踐驗證，能有效解決問題，在各行種業的業務應用系統中起着重要做用。但回到原點來思考，這些方案的採用實際上都是迫於無奈。

回到問題：

與基於消息的最終一致、TCC、Saga等業務邏輯侵入方案的不一樣在於，Fescar 的設計初衷就是保持對業務的非侵入性，不要求業務層面按照分佈式事務的特定場景來設計正向和反向的兩套（甚至多套）業務邏輯。這方面的差異就不展開了。

與 XA 的區別在於，設計了一套不一樣與 XA 的兩階段協議，在保持對業務不侵入的前提下，保證良好的性能，也避免了對底層數據庫協議支持的要求。能夠看做是一套輕量級的XA 機制。具體的差異以下：

• 架構層次

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

而 Fescar 的RM 是以二方包的形式做爲中間件層部署在應用程序這一側的，不依賴與數據庫自己對協議的支持，固然也不須要數據庫支持XA 協議。這點對於微服務化的架構來講是很是重要的：應用層不須要爲本地事務和分佈式事務兩類不一樣場景來適配兩套不一樣的數據庫驅動。

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

• 兩階段提交 先來看一下 XA 的2PC 過程。

不管 Phase2 的決議是commit 仍是 rollback，事務性資源的鎖都要保持到Phase2 完成才釋放。

再看 Fescar 的2PC 過程。

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

同時，隨着本地事務結束，鏈接 也得以釋放。

分支事務中數據的 全局鎖 在事務協調器側管理，在決議 Phase2 全局提交時，全局鎖立刻

能夠釋放。只有在決議全局回滾的狀況下，全局鎖 才被持有至分支的 Phase2 結束。

這個設計，極大地減小了分支事務對資源（數據和鏈接）的鎖定時間，給總體併發和吞吐的提高提供了基礎。

Fescar 支持 Dubbo 的哪些版本？

Q4：Fescar 支持 Dubbo 的哪些版本？

A4：全部版本。

Fescar 支持 Spring Cloud麼？

Q5：Fescar 支持 Spring Cloud麼？

A5：Fescar 與微服務框架的接口點在於，須要把事務的惟一標識 XID（一個字符串）經過微服務框架的服務調用間調用的機制中，透明地傳遞，並經過 Fescar 的 API 來綁定（或解綁）到應用的線程上下文中。（機制能夠參考內置的對 Dubbo 支持的實現 com.alibaba.fescar.dubbo.TransactionPropagationFilter）因此，本質上這個問題不是支不支持 Spring Cloud，而是如何支持 Spring Cloud 中選用的服務調用機制。目前正在和 Spring Cloud Alibaba 的同窗合做，準備在v0.5.x版本（或更早）發佈對 Spring Cloud默認的支持。同時，很是歡迎社區的朋友參與進來，貢獻包括 Spring Cloud 在內的各種微服務框架的支持。

Fescar 是否支持本地跨庫多數據源？除了關係型數據庫，是否還支持NoSQL數據庫？

Q6：Fescar 是否支持本地跨庫多數據源？除了關係型數據庫，是否還支持NoSQL數據庫？

A6：本地跨多數據源一樣是支持的，在 Fescar 的架構中，同一個服務中的多個數據源與跨服務的多個數據源，沒有本質區別。AT 模式目前僅限於對關係型數據庫的支持（自己具有ACID 事務支持），後面會發布出來的 MT 模式能夠支持 NoSQL 這類自己不具有本地事務支持的資源。

Fescar 如今開源的是AT模式，MT模式暫時不支持，何時會開源？

Q7：Fescar 如今開源的是AT模式，MT模式暫時不支持，何時會開源？

A7：當前 0.1.0 版本只是把 Fescar 最核心的 AT 模式的最小集發佈出來，一方面是按開源的規劃和架構的重構進展，另外一方面也是但願經過最小集版本，讓用戶和開發者社區更容易理解到咱們核心的設計思路，讓更多人比較容易地參與進來建設，而不是徹底由阿里巴巴主導，僅僅把咱們的整套方案開源出來給你們用而已。阿里巴巴在分佈式事務上的技術積累，咱們會經過 Fescar 項目毫無保留地貢獻給社區，全部功能特性都會按規劃和社區的反饋陸續開源出來。MT 按初步的計劃，會在 0.5.x 版本發佈。

Fescar 何時提供HA cluster，單節點的server的瓶頸如何處理？

Q8：Fescar 何時提供HA cluster，單節點的server的瓶頸如何處理？

A8：按初步的計劃，HA Cluster 會在 0.5.x 版本發佈，解決單機部署的單點問題。

因網絡中斷、網張閃斷、節點宕機和超時等引發的異常，Fescar會提供相應的補償措施麼？

Q9：因網絡中斷、網張閃斷、節點宕機和超時等引發的異常，Fescar會提供相應的補償措施麼？

A9：這些異常狀況的處理是分佈式事務解決方案的基本要求，Fescar 一樣也是提供了整套方案來處理各種異常場景。這方面的具體機制會在 HA Cluster 版本發佈時，給出全面的分析介紹。

Fescar框架中，如何監控分佈式事務？

Q10：Fescar框架中，如何監控分佈式事務？

A10：監控是很是重要的一起內容。TXC 和 GTS 的監控在阿里巴巴內部使用了不少基礎設施的輔助。而在開源版本中，咱們尚未一個現成的監控方案。大致上，監控的基礎是兩個方面：一方面是日誌，經過日誌的採集和處理，能夠造成一個完整的事務鏈路，這些數據對於業務層面的分析和調優是重要的參考依據。另外一方面是 API，Fescar 會提供一套管控 API，用於對運行時事務的管理。咱們後續會把這兩方面的數據格式、部署形態及接口整理出來，但願和社區來共建監控這個重要的方面。

Fescar 的roadmap 有了麼？

Q11：Fescar 的roadmap 有了麼？

A11：目前最新的roadmap以下： 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

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

Fescar 官網何時上線？

Q12：Fescar 官網何時上線？

A12：Fescar 官方域名已經註冊，官網將採用靜態開源站點搭建工具Docsite「傳送門」進行搭建，logo 已經設計並將於近期公佈。

如何加入 Fescar 社區

Q13：如何加入 Fescar 社區，進行貢獻，已經摩拳擦掌了。

A13：咱們很是歡迎你們經過各類形式參與到咱們項目的建設中，包括但不限於：

• 架構設計
• 模塊設計
• 代碼實現
• Bug Fix
• Demo樣例
• 文檔、網站和翻譯

具體的參與方法能夠參見咱們項目中的CONTRIBUTING 指引，或與 @eternaltingting@163.com 聯繫。實際上，咱們並不拘泥於貢獻的形式，開發者提出的每個 issue，不管是Bug Report、改進建議或者甚至是問題諮詢都表明着對項目的關注和幫助。但願 Fescar 項目和社區一塊兒健康成長，成爲分佈式事務領域一個優秀的解決方案。

本文做者：煊檍，社區暱稱sharajava，Fescar 開源項目發起人，阿里巴巴中件間 TXC/GTS 研發團隊負責人，曾多年從事 WebLogic 核心研發工做，長期專一於中間件，在分佈式事務領域的技術實踐較豐富。

---

歡迎關注阿里巴巴中間件官方微博