99热在线精品一区二区三区_国产伦精品一区二区三区女破破_亚洲一区二区三区无码_精品国产欧美日韩另类一区

開源分布式事務(wù)解決方案Fescar的全解析是怎樣的，很多新手對(duì)此不是很清楚，為了幫助大家解決這個(gè)難題，下面小編將為大家詳細(xì)講解，有這方面需求的人可以來學(xué)習(xí)下，希望你能有所收獲。

創(chuàng)新互聯(lián)成立以來不斷整合自身及行業(yè)資源、不斷突破觀念以使企業(yè)策略得到完善和成熟，建立了一套“以技術(shù)為基點(diǎn)，以客戶需求中心、市場為導(dǎo)向”的快速反應(yīng)體系。對(duì)公司的主營項(xiàng)目，如中高端企業(yè)網(wǎng)站企劃 / 設(shè)計(jì)、行業(yè) / 企業(yè)門戶設(shè)計(jì)推廣、行業(yè)門戶平臺(tái)運(yùn)營、成都App制作、手機(jī)網(wǎng)站開發(fā)、微信網(wǎng)站制作、軟件開發(fā)、服務(wù)器托管等實(shí)行標(biāo)準(zhǔn)化操作，讓客戶可以直觀的預(yù)知到從創(chuàng)新互聯(lián)可以獲得的服務(wù)效果。

廣為人知的阿里分布式事務(wù)解決方案：GTS（Global Transaction Service），已正式推出開源版本，取名為“Fescar”，希望幫助業(yè)界解決微服務(wù)架構(gòu)下的分布式事務(wù)問題，今天我們一起來深入了解。

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

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

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

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

cdn.com/b739529e7894d04f964871a75529b427d4fcd879.png">

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

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

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

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

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

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

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

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

2.1 設(shè)計(jì)初衷

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

• 一方面，不應(yīng)該因?yàn)榧夹g(shù)架構(gòu)上的微服務(wù)化和分布式事務(wù)支持的引入，給業(yè)務(wù)層面帶來額外的研發(fā)負(fù)擔(dān)。

• 另一方面，引入分布式事務(wù)支持的業(yè)務(wù)應(yīng)該基本保持在同一量級(jí)上的性能表現(xiàn)，不能因?yàn)槭聞?wù)機(jī)制顯著拖慢業(yè)務(wù)。

基于這兩點(diǎn)，我們?cè)O(shè)計(jì)之初的最重要的考量就在于：

• 對(duì)業(yè)務(wù)無侵入：這里的“侵入”是指，因?yàn)榉植际绞聞?wù)這個(gè)技術(shù)問題的制約，要求應(yīng)用在業(yè)務(wù)層面進(jìn)行設(shè)計(jì)和改造。這種設(shè)計(jì)和改造往往會(huì)給應(yīng)用帶來很高的研發(fā)和維護(hù)成本。我們希望把分布式事務(wù)問題在 中間件 這個(gè)層次解決掉，不要求應(yīng)用在業(yè)務(wù)層面做額外的工作。

• 高性能：引入分布式事務(wù)的保障，必然會(huì)有額外的開銷，引起性能的下降。我們希望把分布式事務(wù)引入的性能損耗降到非常低的水平，讓應(yīng)用不因?yàn)榉植际绞聞?wù)的引入導(dǎo)致業(yè)務(wù)的可用性受影響。

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

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

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

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

• 要求數(shù)據(jù)庫提供對(duì) XA 的支持。如果遇到不支持 XA（或支持得不好，比如 MySQL 5.7 以前的版本）的數(shù)據(jù)庫，則不能使用。

• 受協(xié)議本身的約束，事務(wù)資源的鎖定周期長。長周期的資源鎖定從業(yè)務(wù)層面來看，往往是不必要的，而因?yàn)槭聞?wù)資源的管理器是數(shù)據(jù)庫本身，應(yīng)用層無法插手。這樣形成的局面就是，基于 XA 的應(yīng)用往往性能會(huì)比較差，而且很難優(yōu)化。

• 已經(jīng)落地的基于 XA 的分布式解決方案，都依托于重量級(jí)的應(yīng)用服務(wù)器（Tuxedo/WebLogic/WebSphere 等)，這是不適用于微服務(wù)架構(gòu)的。

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

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

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

• TCC

• Saga

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

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

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

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

3. 原理和設(shè)計(jì)

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

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

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

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

• Transaction Coordinator (TC)：事務(wù)協(xié)調(diào)器，維護(hù)全局事務(wù)的運(yùn)行狀態(tài)，負(fù)責(zé)協(xié)調(diào)并驅(qū)動(dòng)全局事務(wù)的提交或回滾。

• Transaction Manager (TM)：控制全局事務(wù)的邊界，負(fù)責(zé)開啟一個(gè)全局事務(wù)，并最終發(fā)起全局提交或全局回滾的決議。

• Resource Manager (RM)：控制分支事務(wù)，負(fù)責(zé)分支注冊(cè)、狀態(tài)匯報(bào)，并接收事務(wù)協(xié)調(diào)器的指令，驅(qū)動(dòng)分支（本地）事務(wù)的提交和回滾。

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

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

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

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

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

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

至此，F(xiàn)escar 的協(xié)議機(jī)制總體上看與 XA 是一致的。

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

架構(gòu)層次

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

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

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

兩階段提交

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

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

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

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

當(dāng)然，你肯定會(huì)問：Phase1 即提交的情況下，Phase2 如何回滾呢？

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

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

Phase1：

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

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

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

Phase2：

如果決議是全局提交，此時(shí)分支事務(wù)此時(shí)已經(jīng)完成提交，不需要同步協(xié)調(diào)處理（只需要異步清理回滾日志），Phase2 可以非?？焖俚赝瓿伞?/p>

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

3.4 事務(wù)傳播機(jī)制

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

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

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

• PROPAGATION_REQUIRED：默認(rèn)支持

• PROPAGATION_SUPPORTS：默認(rèn)支持

• PROPAGATION_MANDATORY：應(yīng)用通過 API 來實(shí)現(xiàn)

• PROPAGATION_REQUIRES_NEW：應(yīng)用通過 API 來實(shí)現(xiàn)

• PROPAGATION_NOT_SUPPORTED：應(yīng)用通過 API 來實(shí)現(xiàn)

• PROPAGATION_NEVER：應(yīng)用通過 API 來實(shí)現(xiàn)

• PROPAGATION_REQUIRED_NESTED：不支持

3.5 隔離性

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

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

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

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

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

4. 適用場景分析

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

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

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

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

4.1 分支的基本行為模式

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

• 分支注冊(cè)：在分支事務(wù)的數(shù)據(jù)操作進(jìn)行之前，需要向協(xié)調(diào)器注冊(cè)，把即將進(jìn)行的分支事務(wù)數(shù)據(jù)操作，納入一個(gè)已經(jīng)開啟的全局事務(wù)的管理中去，在分支注冊(cè)成功后，才可以進(jìn)行數(shù)據(jù)操作。

• 狀態(tài)上報(bào)：在分支事務(wù)的數(shù)據(jù)操作完成后，需要向事務(wù)協(xié)調(diào)器上報(bào)其執(zhí)行結(jié)果。

• 分支提交：響應(yīng)協(xié)調(diào)器發(fā)出的分支事務(wù)提交的請(qǐng)求，完成分支提交。

• 分支回滾：響應(yīng)協(xié)調(diào)器發(fā)出的分支事務(wù)回滾的請(qǐng)求，完成分支回滾。

4.2 AT 模式分支的行為模式

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

4.3 MT 模式分支的行為模式

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

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

4.4 混合模式

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

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

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

5. 擴(kuò)展點(diǎn)

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

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

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

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

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

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

5.4 MT 模式的場景拓展

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

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

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

6. Roadmap

藍(lán)圖

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

• 對(duì)不同數(shù)據(jù)庫的支持，開發(fā)者可以參考 MySQL 的實(shí)現(xiàn)。

• 對(duì)不同微服務(wù)框架的支持，開發(fā)者可以參考 Dubbo 的實(shí)現(xiàn)。

• 對(duì) MQ、NOSQL 的支持，開發(fā)者可以參考 TCC 的實(shí)現(xiàn)。

• 配置和服務(wù)注冊(cè)發(fā)現(xiàn)：開發(fā)者通過少量的工作可以接入任何可以提供這類服務(wù)的框架。

• 當(dāng)然，非 藍(lán)色 的部分也非常歡迎社區(qū)參與進(jìn)來，貢獻(xiàn)更優(yōu)的解決方案。

• 另外，XA 作為分布式事務(wù)的標(biāo)準(zhǔn)，是一個(gè)完備的分布式事務(wù)解決方案不可或缺的，遠(yuǎn)景的規(guī)劃中，我們一定需要把 XA 的支持加入進(jìn)來。

初步的版本規(guī)劃

v0.1.0：

• 微服務(wù)框架支持: Dubbo

• 數(shù)據(jù)庫支持: MySQL

• 基于 Spring AOP 的 Annotation

• 事務(wù)協(xié)調(diào)器: 單機(jī)版本

v0.5.x：

• 微服務(wù)框架支持: Spring Cloud

• MT 模式

• 支持 TCC 模式事務(wù)的適配

• 動(dòng)態(tài)配置和服務(wù)發(fā)現(xiàn)

• 事務(wù)協(xié)調(diào)器: 高可用集群版本

v0.8.x：

• Metrics

• 控制臺(tái): 監(jiān)控/部署/升級(jí)/擴(kuò)縮容

v1.0.0：

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

v1.5.x：

• 數(shù)據(jù)庫支持: Oracle/PostgreSQL/OceanBase

• 不依賴 Spring AOP 的 Annotation

• 熱點(diǎn)數(shù)據(jù)的優(yōu)化處理機(jī)制

• RocketMQ 事務(wù)消息納入全局事務(wù)管理

• NoSQL 納入全局事務(wù)管理的適配機(jī)制

• 支持 HBase

• 支持 Redis

v2.0.0：

• 支持 XA

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

看完上述內(nèi)容是否對(duì)您有幫助呢？如果還想對(duì)相關(guān)知識(shí)有進(jìn)一步的了解或閱讀更多相關(guān)文章，請(qǐng)關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝您對(duì)創(chuàng)新互聯(lián)的支持。

分享文章：開源分布式事務(wù)解決方案Fescar的全解析是怎樣的
當(dāng)前URL：http://ef60e0e.cn/article/pogdip.html