當前位置：首頁 >

阿里开源分布式事务解决方案 Fescar

發(fā)布時間：2024/9/5 61 豆豆

生活随笔收集整理的這篇文章主要介紹了阿里开源分布式事务解决方案 Fescar 小編覺得挺不錯的,現(xiàn)在分享給大家,幫大家做個參考.

微服務(wù)倡導(dǎo)將復(fù)雜的單體應(yīng)用拆分為若干個功能簡單、松耦合的服務(wù)，這樣可以降低開發(fā)難度、增強擴展性、便于敏捷開發(fā)。當前被越來越多的開發(fā)者推崇，系統(tǒng)微服務(wù)化后，一個看似簡單的功能，內(nèi)部可能需要調(diào)用多個服務(wù)并操作多個數(shù)據(jù)庫實現(xiàn)，服務(wù)調(diào)用的分布式事務(wù)問題變的非常突出。分布式事務(wù)已經(jīng)成為微服務(wù)落地最大的阻礙，也是最具挑戰(zhàn)性的一個技術(shù)難題。??

1. 什么是微服務(wù)化帶來的分布式事務(wù)問題？

首先，設(shè)想一個傳統(tǒng)的單體應(yīng)用（Monolithic App），通過 3 個 Module，在同一個數(shù)據(jù)源上更新數(shù)據(jù)來完成一項業(yè)務(wù)。

很自然的，整個業(yè)務(wù)過程的數(shù)據(jù)一致性由本地事務(wù)來保證。

隨著業(yè)務(wù)需求和架構(gòu)的變化，單體應(yīng)用被拆分為微服務(wù)：原來的 3 個 Module 被拆分為 3 個獨立的服務(wù)，分別使用獨立的數(shù)據(jù)源（Pattern: Database per service）。業(yè)務(wù)過程將由 3 個服務(wù)的調(diào)用來完成。

此時，每一個服務(wù)內(nèi)部的數(shù)據(jù)一致性仍有本地事務(wù)來保證。而整個業(yè)務(wù)層面的全局數(shù)據(jù)一致性要如何保障呢？這就是微服務(wù)架構(gòu)下面臨的，典型的分布式事務(wù)需求：我們需要一個分布式事務(wù)的解決方案保障業(yè)務(wù)全局的數(shù)據(jù)一致性。

?

2. Fescar 的發(fā)展歷程

阿里是國內(nèi)最早一批進行應(yīng)用分布式（微服務(wù)化）改造的企業(yè)，所以很早就遇到微服務(wù)架構(gòu)下的分布式事務(wù)問題。

2014 年，阿里中間件團隊發(fā)布?TXC（Taobao Transaction Constructor），為集團內(nèi)應(yīng)用提供分布式事務(wù)服務(wù)。

2016 年，TXC 經(jīng)過產(chǎn)品化改造，以?GTS（Global Transaction Service）的身份登陸阿里云，成為當時業(yè)界唯一一款云上分布式事務(wù)產(chǎn)品，在阿云里的公有云、專有云解決方案中，開始服務(wù)于眾多外部客戶。

2019 年起，基于 TXC 和 GTS 的技術(shù)積累，阿里中間件團隊發(fā)起了開源項目?Fescar（Fast & EaSy Commit And Rollback, FESCAR），和社區(qū)一起建設(shè)這個分布式事務(wù)解決方案。

TXC/GTS/Fescar 一脈相承，為解決微服務(wù)架構(gòu)下的分布式事務(wù)問題交出了一份與眾不同的答卷。

?

2.1 設(shè)計初衷

高速增長的互聯(lián)網(wǎng)時代，快速試錯的能力對業(yè)務(wù)來說是至關(guān)重要的：

一方面，不應(yīng)該因為技術(shù)架構(gòu)上的微服務(wù)化和分布式事務(wù)支持的引入，給業(yè)務(wù)層面帶來額外的研發(fā)負擔(dān)。
另一方面，引入分布式事務(wù)支持的業(yè)務(wù)應(yīng)該基本保持在同一量級上的性能表現(xiàn)，不能因為事務(wù)機制顯著拖慢業(yè)務(wù)。

基于這兩點，我們設(shè)計之初的最重要的考量就在于：

對業(yè)務(wù)無侵入：這里的“侵入”是指，因為分布式事務(wù)這個技術(shù)問題的制約，要求應(yīng)用在業(yè)務(wù)層面進行設(shè)計和改造。這種設(shè)計和改造往往會給應(yīng)用帶來很高的研發(fā)和維護成本。我們希望把分布式事務(wù)問題在中間件這個層次解決掉，不要求應(yīng)用在業(yè)務(wù)層面做額外的工作。
高性能：引入分布式事務(wù)的保障，必然會有額外的開銷，引起性能的下降。我們希望把分布式事務(wù)引入的性能損耗降到非常低的水平，讓應(yīng)用不因為分布式事務(wù)的引入導(dǎo)致業(yè)務(wù)的可用性受影響。

?

2.2 既有的解決方案為什么不滿足？

既有的分布式事務(wù)解決方案按照對業(yè)務(wù)侵入性分為兩類，即：對業(yè)務(wù)無侵入的和對業(yè)務(wù)有侵入的。

?

★業(yè)務(wù)無侵入的方案

既有的主流分布式事務(wù)解決方案中，對業(yè)務(wù)無侵入的只有基于 XA 的方案，但應(yīng)用 XA 方案存在 3 個方面的問題：

要求數(shù)據(jù)庫提供對 XA 的支持。如果遇到不支持 XA（或支持得不好，比如 MySQL 5.7 以前的版本）的數(shù)據(jù)庫，則不能使用。
受協(xié)議本身的約束，事務(wù)資源的鎖定周期長。長周期的資源鎖定從業(yè)務(wù)層面來看，往往是不必要的，而因為事務(wù)資源的管理器是數(shù)據(jù)庫本身，應(yīng)用層無法插手。這樣形成的局面就是，基于 XA 的應(yīng)用往往性能會比較差，而且很難優(yōu)化。
已經(jīng)落地的基于 XA 的分布式解決方案，都依托于重量級的應(yīng)用服務(wù)器（Tuxedo/WebLogic/WebSphere 等)，這是不適用于微服務(wù)架構(gòu)的。

?

★侵入業(yè)務(wù)的方案

實際上，最初分布式事務(wù)只有 XA 這個唯一方案。XA 是完備的，但在實踐過程中，由于種種原因（包含但不限于上面提到的 3 點）往往不得不放棄，轉(zhuǎn)而從業(yè)務(wù)層面著手來解決分布式事務(wù)問題。比如：

基于可靠消息的最終一致性方案
TCC
Saga

都屬于這一類。這些方案的具體機制在這里不做展開，網(wǎng)上這方面的論述文章非常多。總之，這些方案都要求在應(yīng)用的業(yè)務(wù)層面把分布式事務(wù)技術(shù)約束考慮到設(shè)計中，通常每一個服務(wù)都需要設(shè)計實現(xiàn)正向和反向的冪等接口。這樣的設(shè)計約束，往往會導(dǎo)致很高的研發(fā)和維護成本。

?

2.3 理想的方案應(yīng)該是什么樣子？

不可否認，侵入業(yè)務(wù)的分布式事務(wù)方案都經(jīng)過大量實踐驗證，能有效解決問題，在各種行業(yè)的業(yè)務(wù)應(yīng)用系統(tǒng)中起著重要作用。但回到原點來思考，這些方案的采用實際上都是迫于無奈。設(shè)想，如果基于 XA 的方案能夠不那么重，并且能保證業(yè)務(wù)的性能需求，相信不會有人愿意把分布式事務(wù)問題拿到業(yè)務(wù)層面來解決。

一個理想的分布式事務(wù)解決方案應(yīng)該：像使用本地事務(wù)一樣簡單，業(yè)務(wù)邏輯只關(guān)注業(yè)務(wù)層面的需求，不需要考慮事務(wù)機制上的約束。

?

3. 原理和設(shè)計

我們要設(shè)計一個對業(yè)務(wù)無侵入的方案，所以從業(yè)務(wù)無侵入的 XA 方案來思考：是否可以在 XA 的基礎(chǔ)上演進，解決掉 XA 方案面臨的問題呢？

?

3.1 如何定義一個分布式事務(wù)？

首先，很自然的，我們可以把一個分布式事務(wù)理解成一個包含了若干分支事務(wù)的全局事務(wù)。全局事務(wù)的職責(zé)是協(xié)調(diào)其下管轄的?分支事務(wù)?達成一致，要么一起成功提交，要么一起失敗回滾。此外，通常分支事務(wù)本身就是一個滿足 ACID 的本地事務(wù)。這是我們對分布式事務(wù)結(jié)構(gòu)的基本認識，與 XA 是一致的。

其次，與 XA 的模型類似，我們定義 3 個組件來協(xié)議分布式事務(wù)的處理過程。

Transaction Coordinator (TC)：事務(wù)協(xié)調(diào)器，維護全局事務(wù)的運行狀態(tài)，負責(zé)協(xié)調(diào)并驅(qū)動全局事務(wù)的提交或回滾。
Transaction Manager (TM)：控制全局事務(wù)的邊界，負責(zé)開啟一個全局事務(wù)，并最終發(fā)起全局提交或全局回滾的決議。
Resource Manager (RM)：控制分支事務(wù)，負責(zé)分支注冊、狀態(tài)匯報，并接收事務(wù)協(xié)調(diào)器的指令，驅(qū)動分支（本地）事務(wù)的提交和回滾。

一個典型的分布式事務(wù)過程：

TM 向 TC 申請開啟一個全局事務(wù)，全局事務(wù)創(chuàng)建成功并生成一個全局唯一的 XID。

XID 在微服務(wù)調(diào)用鏈路的上下文中傳播。

RM 向 TC 注冊分支事務(wù)，將其納入 XID 對應(yīng)全局事務(wù)的管轄。

TM 向 TC 發(fā)起針對 XID 的全局提交或回滾決議。

TC 調(diào)度 XID 下管轄的全部分支事務(wù)完成提交或回滾請求。

至此，Fescar 的協(xié)議機制總體上看與 XA 是一致的。

?

3.2 與 XA 的差別在什么地方？

?

★架構(gòu)層次

XA 方案的 RM 實際上是在數(shù)據(jù)庫層，RM 本質(zhì)上就是數(shù)據(jù)庫自身（通過提供支持 XA 的驅(qū)動程序來供應(yīng)用使用）。

而 Fescar 的 RM 是以二方包的形式作為中間件層部署在應(yīng)用程序這一側(cè)的，不依賴與數(shù)據(jù)庫本身對協(xié)議的支持，當然也不需要數(shù)據(jù)庫支持 XA 協(xié)議。這點對于微服務(wù)化的架構(gòu)來說是非常重要的：應(yīng)用層不需要為本地事務(wù)和分布式事務(wù)兩類不同場景來適配兩套不同的數(shù)據(jù)庫驅(qū)動。

這個設(shè)計，剝離了分布式事務(wù)方案對數(shù)據(jù)庫在?協(xié)議支持?上的要求。

?

★兩階段提交

先來看一下 XA 的 2PC 過程。

無論 Phase2 的決議是 commit 還是 rollback，事務(wù)性資源的鎖都要保持到 Phase2 完成才釋放。

設(shè)想一個正常運行的業(yè)務(wù)，大概率是 90% 以上的事務(wù)最終應(yīng)該是成功提交的，我們是否可以在 Phase1 就將本地事務(wù)提交呢？這樣 90% 以上的情況下，可以省去 Phase2 持鎖的時間，整體提高效率。

這個設(shè)計，在絕大多數(shù)場景減少了事務(wù)持鎖時間，從而提高了事務(wù)的并發(fā)度。

當然，你肯定會問：Phase1 即提交的情況下，Phase2 如何回滾呢？

?

3.3 分支事務(wù)如何提交和回滾？

首先，應(yīng)用需要使用 Fescar 的 JDBC 數(shù)據(jù)源代理，也就是 Fescar 的 RM。

★Phase1：

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

這樣，可以保證：任何提交的業(yè)務(wù)數(shù)據(jù)的更新一定有相應(yīng)的回滾日志存在。

基于這樣的機制，分支的本地事務(wù)便可以在全局事務(wù)的 Phase1 提交，馬上釋放本地事務(wù)鎖定的資源。

★Phase2：

如果決議是全局提交，此時分支事務(wù)此時已經(jīng)完成提交，不需要同步協(xié)調(diào)處理（只需要異步清理回滾日志），Phase2 可以非常快速地完成。

如果決議是全局回滾，RM 收到協(xié)調(diào)器發(fā)來的回滾請求，通過 XID 和 Branch ID 找到相應(yīng)的回滾日志記錄，通過回滾記錄生成反向的更新 SQL 并執(zhí)行，以完成分支的回滾。

3.4 事務(wù)傳播機制

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

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

對應(yīng)到 Java EE 規(guī)范和 Spring 定義的事務(wù)傳播屬性，Fescar 的支持如下：

PROPAGATION_REQUIRED：默認支持
PROPAGATION_SUPPORTS：默認支持
PROPAGATION_MANDATORY：應(yīng)用通過 API 來實現(xiàn)
PROPAGATION_REQUIRES_NEW：應(yīng)用通過 API 來實現(xiàn)
PROPAGATION_NOT_SUPPORTED：應(yīng)用通過 API 來實現(xiàn)
PROPAGATION_NEVER：應(yīng)用通過 API 來實現(xiàn)
PROPAGATION_REQUIRED_NESTED：不支持

?

3.5 隔離性

全局事務(wù)的隔離性是建立在分支事務(wù)的本地隔離級別基礎(chǔ)之上的。

在數(shù)據(jù)庫本地隔離級別讀已提交或以上的前提下，Fescar 設(shè)計了由事務(wù)協(xié)調(diào)器維護的?全局寫排他鎖，來保證事務(wù)間的寫隔離，將全局事務(wù)默認定義在讀未提交的隔離級別上。

我們對隔離級別的共識是：絕大部分應(yīng)用在?讀已提交?的隔離級別下工作是沒有問題的。而實際上，這當中又有絕大多數(shù)的應(yīng)用場景，實際上工作在讀未提交的隔離級別下同樣沒有問題。

在極端場景下，應(yīng)用如果需要達到全局的?讀已提交，Fescar 也提供了相應(yīng)的機制來達到目的。默認，Fescar 是工作在?讀無提交?的隔離級別下，保證絕大多數(shù)場景的高效性。

事務(wù)的 ACID 屬性在 Fescar 中的體現(xiàn)是一個比較復(fù)雜的話題，我們會有專門的文章來深入分析，這里不做進一步展開。

?

4. 適用場景分析

前文所述的 Fescar 的核心原理中有一個重要前提：分支事務(wù)中涉及的資源，必須是支持ACID 事務(wù)的?關(guān)系型數(shù)據(jù)庫。分支的提交和回滾機制，都依賴于本地事務(wù)的保障。所以，如果應(yīng)用使用的數(shù)據(jù)庫是不支持事務(wù)的，或根本不是關(guān)系型數(shù)據(jù)庫，就不適用。

另外，目前 Fescar 的實現(xiàn)還存在一些局限，比如：事務(wù)隔離級別最高支持到讀已提交的水平，SQL 的解析還不能涵蓋全部的語法等。

為了覆蓋 Fescar 原生機制暫時不能支持應(yīng)用場景，我們定義了另外一種工作模式。

上面介紹的 Fescar 原生工作模式稱為 AT（Automatic Transaction）模式，這種模式是對業(yè)務(wù)無侵入的。與之相應(yīng)的另外一種工作模式稱為 MT（Manual Transaction）模式，這種模式下，分支事務(wù)需要應(yīng)用自己來定義業(yè)務(wù)本身及提交和回滾的邏輯。

?

4.1 分支的基本行為模式

作為全局事務(wù)一部分的分支事務(wù)，除本身的業(yè)務(wù)邏輯外，都包含 4 個與協(xié)調(diào)器交互的行為：

分支注冊：在分支事務(wù)的數(shù)據(jù)操作進行之前，需要向協(xié)調(diào)器注冊，把即將進行的分支事務(wù)數(shù)據(jù)操作，納入一個已經(jīng)開啟的全局事務(wù)的管理中去，在分支注冊成功后，才可以進行數(shù)據(jù)操作。
狀態(tài)上報：在分支事務(wù)的數(shù)據(jù)操作完成后，需要向事務(wù)協(xié)調(diào)器上報其執(zhí)行結(jié)果。
分支提交：響應(yīng)協(xié)調(diào)器發(fā)出的分支事務(wù)提交的請求，完成分支提交。
分支回滾：響應(yīng)協(xié)調(diào)器發(fā)出的分支事務(wù)回滾的請求，完成分支回滾。

4.2 AT 模式分支的行為模式

業(yè)務(wù)邏輯不需要關(guān)注事務(wù)機制，分支與全局事務(wù)的交互過程自動進行。

?

4.3 MT 模式分支的行為模式

業(yè)務(wù)邏輯需要被分解為 Prepare/Commit/Rollback 3 部分，形成一個 MT 分支，加入全局事務(wù)。

MT 模式一方面是 AT 模式的補充。另外，更重要的價值在于，通過 MT 模式可以把眾多非事務(wù)性資源納入全局事務(wù)的管理中。

4.4 混合模式

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

4.5 應(yīng)用場景的遠景

回到我們設(shè)計的初衷：一個理想的分布式事務(wù)解決方案是不應(yīng)該侵入業(yè)務(wù)的。MT 模式是在 AT 模式暫時不能完全覆蓋所有場景的情況下，一個比較自然的補充方案。我們希望通過 AT 模式的不斷演進增強，逐步擴大所支持的場景，MT 模式逐步收斂。未來，我們會納入對 XA 的原生支持，用 XA 這種無侵入的方式來覆蓋 AT 模式無法觸達的場景。

5. 擴展點

5.1 微服務(wù)框架的支持

事務(wù)上下文在微服務(wù)間的傳播需要根據(jù)微服務(wù)框架本身的機制，訂制最優(yōu)的，對應(yīng)用層透明的解決方案。有興趣在這方面共建的開發(fā)者可以參考內(nèi)置的對 Dubbo 的支持方案，來實現(xiàn)對其他微服務(wù)框架的支持。

5.2 所支持的數(shù)據(jù)庫類型

因為 AT 涉及 SQL 的解析，所以在不同類型的數(shù)據(jù)庫上工作，會有一些特定的適配。有興趣在這方面共建的開發(fā)者可以參考內(nèi)置的對 MySQL 的支持方案，來實現(xiàn)對其他數(shù)據(jù)庫的支持。

5.3 配置和服務(wù)注冊發(fā)現(xiàn)

支持接入不同的配置和服務(wù)注冊發(fā)現(xiàn)解決方案。比如：Nacos、Eureka、ZooKeeper 等。

5.4 MT 模式的場景拓展

MT 模式的一個重要作用就是，可以把非關(guān)系型數(shù)據(jù)庫的資源，通過 MT 模式分支的包裝，納入到全局事務(wù)的管轄中來。比如，Redis、HBase、RocketMQ 的事務(wù)消息等。有興趣在這方面共建的開發(fā)者可以在這里貢獻一系列相關(guān)生態(tài)的適配方案。

5.5 事務(wù)協(xié)調(diào)器的分布式高可用方案

針對不同場景，支持不同的方式作為事務(wù)協(xié)調(diào)器 Server 端的高可用方案。比如，針對事務(wù)狀態(tài)的持久化，可以是基于文件的實現(xiàn)方案，也可以是基于數(shù)據(jù)庫的實現(xiàn)方案；集群間的狀態(tài)同步，可以是基于 RPC 通信的方案，也可以是基于高可用 KV 存儲的方案。

6. Roadmap

藍圖

綠色部分是已經(jīng)開源發(fā)布出來的，黃色?部分是將在后續(xù)版本中由阿里發(fā)布出來的，藍色部分是我們和社區(qū)共建生態(tài)部分：

對不同數(shù)據(jù)庫的支持，開發(fā)者可以參考 MySQL 的實現(xiàn)。
對不同微服務(wù)框架的支持，開發(fā)者可以參考 Dubbo 的實現(xiàn)。
對 MQ、NoSQL 的支持，開發(fā)者可以參考 TCC 的實現(xiàn)。
配置和服務(wù)注冊發(fā)現(xiàn)：開發(fā)者通過少量的工作可以接入任何可以提供這類服務(wù)的框架。
當然，非藍色的部分也非常歡迎社區(qū)參與進來，貢獻更優(yōu)的解決方案。
另外，XA 作為分布式事務(wù)的標準，是一個完備的分布式事務(wù)解決方案不可或缺的，遠景的規(guī)劃中，我們一定需要把 XA 的支持加入進來。

?

初步的版本規(guī)劃

★v0.1.0：

微服務(wù)框架支持: Dubbo
數(shù)據(jù)庫支持: MySQL
基于 Spring AOP 的 Annotation
事務(wù)協(xié)調(diào)器: 單機版本

?

★v0.5.x：

微服務(wù)框架支持: Spring Cloud
MT 模式
支持 TCC 模式事務(wù)的適配
動態(tài)配置和服務(wù)發(fā)現(xiàn)
事務(wù)協(xié)調(diào)器: 高可用集群版本

?

★v0.8.x：

Metrics
控制臺: 監(jiān)控/部署/升級/擴縮容

?

★v1.0.0：

General Availability: 生產(chǎn)環(huán)境適用

?

★v1.5.x：

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

?

★v2.0.0：

支持 XA

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