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

© Mikito Tateisi

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

為此，我們收集了大家在社區（Github）和社群（釘釘群&微信群）關注的核心問題，總結如下，並給出回覆。

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

• 2014 年

阿里巴巴中間件團隊發佈TXC（Taobao Transaction Constructor），為集團內應用提供分佈式事務服務。

• 2016 年

TXC 經過產品化改造，以

• 2019 年

基於 TXC 和 GTS 的技術積累，阿里巴巴中間件團隊發起了開源項目Fescar（Fast & EaSy Commit And Rollback, FESCAR），和社區一起建設這個分佈式事務解決方案。

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

A2：Fescar 的願景是讓分佈式事務的使用像現在本地事務的使用一樣簡單、高效，最終的目標是希望可以適用於所有的分佈式事務場景。目前，核心的 AT 模式適用於構建於支持本地 ACID 事務的關係型數據庫。非關係型數據庫類資源的管理，通過 MT 模式來支持。AT 模式與 MT 模式完全兼容，所以可以在同一個分佈式事務中，同時管理兩類資源。

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 結束。

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

A4：所有版本。

A5：Fescar 與微服務框架的接口點在於，需要把事務的唯一標識 XID（一個字符串）通過微服務框架的服務調用間調用的機制中，透明地傳遞，並通過 Fescar 的 API 來綁定（或解綁）到應用的線程上下文中。（機制可以參考內置的對 Dubbo 支持的實現 com.alibaba.fescar.dubbo.TransactionPropagationFilter）所以，本質上這個問題不是支不支持 Spring Cloud，而是如何支持 Spring Cloud 中選用的服務調用機制。目前正在和 Spring Cloud Alibaba 的同學合作，準備在

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

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

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

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

A10：監控是非常重要的一塊兒內容。TXC 和 GTS 的監控在阿里巴巴內部使用了很多基礎設施的輔助。而在開源版本中，我們還沒有一個現成的監控方案。大體上，監控的基礎是兩個方面：一方面是日誌，通過日誌的採集和處理，可以形成一個完整的事務鏈路，這些數據對於業務層面的分析和調優是重要的參考依據。另一方面是 API，Fescar 會提供一套管控 API，用於對運行時事務的管理。

A11：目前最新的roadmap如下：

v0.1.0

• 微服務框架支持: Dubbo
• 數據庫支持: MySQL
• 基於 Spring AOP 的 Annotation
• 事務協調器: 單機版本

v0.5.x

• 微服務框架支持: Spring Cloud
• MT 模式
• 支持 TCC 模式事務的適配
• 動態配置和服務發現
• 事務協調器: 高可用集群版本

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

v1.0.0

• General Availability: 生產環境適用

v1.5.x

• 數據庫支持: Oracle/PostgreSQL/OceanBase
• 不依賴 Spring AOP 的 Annotation
• 熱點數據的優化處理機制
• RocketMQ 事務消息納入全局事務管理
• NoSQL 納入全局事務管理的適配機制
• 支持 HBase
• 支持 Redis

v2.0.0

• 支持 XA

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

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

A13：我們非常歡迎大家通過各種形式參與到我們項目的建設中，包括但不限於：

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

具體的參與方法可以參見我們項目中的CONTRIBUTING 指引，或與 @[email protected] 聯繫。實際上，我們並不拘泥於貢獻的形式，開發者提出的每一個 issue，無論是Bug Report、改進建議或者甚至是問題諮詢都代表著對項目的關注和幫助。希望 Fescar 項目和社區一起健康成長，成為分佈式事務領域一個優秀的解決方案。

閱讀更多 中間件小哥 的文章

關鍵字: 分佈式 Java 阿里雲