注：本文轉(zhuǎn)自https://yq.aliyun.com/articles/600584

本文介紹了螞蟻金服在分布式事務(wù)上，經(jīng)過(guò)多年發(fā)展，服務(wù)于內(nèi)外部大量不同業(yè)務(wù)，沉淀出的一整套包含TCC、FMT、XA模型的分布式事務(wù)解決方案。并且在持續(xù)對(duì)外輸出的過(guò)程中，進(jìn)一步打磨產(chǎn)品體驗(yàn)，適應(yīng)各種嚴(yán)苛的金融級(jí)場(chǎng)景和機(jī)構(gòu)需求，比如跨機(jī)房跨地域的容災(zāi)業(yè)務(wù)連續(xù)性保障能力等。

隨著互聯(lián)網(wǎng)技術(shù)快速發(fā)展，數(shù)據(jù)規(guī)模增大，采用分布式數(shù)據(jù)庫(kù)或者跨多個(gè)數(shù)據(jù)庫(kù)的分布式微服務(wù)應(yīng)用在中大規(guī)模企業(yè)普遍存在，而由于網(wǎng)絡(luò)、機(jī)器等不可靠因素，數(shù)據(jù)一致性的問(wèn)題很容易出現(xiàn)，與可擴(kuò)展性、高可用容災(zāi)等要求并肩成為金融IT架構(gòu)支撐業(yè)務(wù)轉(zhuǎn)型升級(jí)的最大挑戰(zhàn)之一。

在螞蟻金服核心系統(tǒng)提出微服務(wù)化時(shí)，曾遇到了非常大的技術(shù)難題。首先是在服務(wù)拆分以后，面臨跨服務(wù)的一致性問(wèn)題；其次，支付寶當(dāng)時(shí)的峰值交易量已經(jīng)非常高了，在解決一致性問(wèn)題的同時(shí)，還需要兼顧性能。

在當(dāng)時(shí)，業(yè)界常用的分布式事務(wù)解決方案，通常能夠?qū)崿F(xiàn)跨服務(wù)一致性，但在熱點(diǎn)數(shù)據(jù)的處理上，難以滿足性能需求。

因此，螞蟻金服微服務(wù)化過(guò)程中急需一種即能保證一致性，又能保證高性能的方案。當(dāng)時(shí)經(jīng)過(guò)一系列調(diào)研和討論，最終選擇了以BASE最終一致性思想為基礎(chǔ)，在業(yè)務(wù)層實(shí)現(xiàn)兩階段提交的TCC分布式事務(wù)解決方案，該方案既能保證跨服務(wù)的最終一致，又能通過(guò)業(yè)務(wù)靈活加鎖的方式大幅減少資源層加鎖時(shí)間，高效處理熱點(diǎn)問(wèn)題。

隨著螞蟻金服業(yè)務(wù)不斷豐富，業(yè)務(wù)邏輯越來(lái)越復(fù)雜，同時(shí)螞蟻金融云上客戶也越來(lái)越多，對(duì)分布式事務(wù)解決方案（簡(jiǎn)稱DTX，Distributed Transaction-eXtended）也不只是追求極限性能，也對(duì)接入便捷性、實(shí)時(shí)一致性有了要求。這篇文章將基于分布式事務(wù)在支付寶/螞蟻金服核心金融場(chǎng)景下的演進(jìn)路線，分享介紹其在各階段的關(guān)鍵設(shè)計(jì)考量和發(fā)展思路。

一. 分布式事務(wù)在螞蟻金服的應(yīng)用背景

1.1 支付寶 SOA 架構(gòu)演進(jìn)

最初的支付寶系統(tǒng)架構(gòu)非常簡(jiǎn)單，是一個(gè)典型的 Web 系統(tǒng)，交易、支付、賬務(wù)系統(tǒng)是沒有分開的，全部集中在一個(gè)大工程里，底層用DB 存儲(chǔ)，Web服務(wù)使用Spring等框架開發(fā)，最上層使用LB轉(zhuǎn)發(fā)用戶流量。

隨著代碼規(guī)模和業(yè)務(wù)邏輯復(fù)雜度的增長(zhǎng)，將所有的業(yè)務(wù)模塊放在一個(gè) Web服務(wù)內(nèi)的缺點(diǎn)日益凸顯。因此推動(dòng)了服務(wù)模塊化拆分，演進(jìn)成SOA架構(gòu)，很好地解決了應(yīng)用的伸縮性問(wèn)題。

在這個(gè)架構(gòu)中，交易系統(tǒng)、支付系統(tǒng)、賬務(wù)系統(tǒng)分別獨(dú)立出來(lái)了，它們之間的調(diào)用靠RPC，除了服務(wù)模塊化拆分，還有數(shù)據(jù)庫(kù)的垂直拆分，根據(jù)業(yè)務(wù)系統(tǒng)功能，將數(shù)據(jù)庫(kù)拆分為多個(gè)，每個(gè)系統(tǒng)使用獨(dú)立的數(shù)據(jù)庫(kù)。

1.2 數(shù)據(jù)一致性問(wèn)題

數(shù)據(jù)垂直拆分后，減少了單庫(kù)的性能瓶頸，但也帶來(lái)了數(shù)據(jù)一致性的問(wèn)題。如下圖所示：

一筆轉(zhuǎn)賬業(yè)務(wù)需要跨交易、支付、賬務(wù)三個(gè)系統(tǒng)才能完成整個(gè)流程，并且要求這三個(gè)系統(tǒng)要么一起成功，要么一起失敗。如果有的成功，有的失敗，就有可能造成數(shù)據(jù)不一致，那么這個(gè)業(yè)務(wù)行為肯定不會(huì)被用戶所理解。所以，我們系統(tǒng)面臨的問(wèn)題就是 SOA 架構(gòu)下的數(shù)據(jù)一致性。

二. 關(guān)鍵設(shè)計(jì)考量：金融級(jí)一致性要求與海量并發(fā)處理能力

考慮到在解決一致性問(wèn)題的同時(shí)，還要兼顧海量并發(fā)處理能力，螞蟻金服內(nèi)部結(jié)合BASE 理論的思想，選擇在業(yè)務(wù)層實(shí)現(xiàn)2PC（兩階段事務(wù)提交）的方式來(lái)解決該問(wèn)題。

BASE 理論是指 BA（Basic Availability，基本業(yè)務(wù)可用性）；S（Soft state，柔性狀態(tài)）；E（Eventual consistency，最終一致性）。該理論認(rèn)為為了可用性、性能與降級(jí)服務(wù)的需要，可以適當(dāng)降低一點(diǎn)一致性的要求，即“基本可用，最終一致”。

一般來(lái)講，在傳統(tǒng)的單機(jī)數(shù)據(jù)庫(kù)或者集中式存儲(chǔ)數(shù)據(jù)庫(kù)里，對(duì)于一致性的要求是實(shí)時(shí)一致；而對(duì)于分布式系統(tǒng)，服務(wù)與服務(wù)之間已經(jīng)實(shí)現(xiàn)了功能的劃分，邏輯的解耦，也就更容易弱化一致性，允許處理過(guò)程中，數(shù)據(jù)的短暫不一致，只需要保證數(shù)據(jù)最終達(dá)到一致。

2.1 分布式金融核心的零差錯(cuò)容忍保證：TCC模型

如本文開篇所述，螞蟻金服大部分系統(tǒng)的分布式事務(wù)解決方案以BASE最終一致性思想為基礎(chǔ)，在業(yè)務(wù)層實(shí)現(xiàn)兩階段提交的TCC（Try-Confirm-Cancel）分布式事務(wù)解決方案，以確保在一致性問(wèn)題的保障和性能方面達(dá)到最佳平衡。

TCC 分布式事務(wù)模型包括三部分，如下所示

主業(yè)務(wù)服務(wù)：主業(yè)務(wù)服務(wù)為整個(gè)業(yè)務(wù)活動(dòng)的發(fā)起方，服務(wù)的編排者，負(fù)責(zé)發(fā)起并完成整個(gè)業(yè)務(wù)活動(dòng)。

從業(yè)務(wù)服務(wù)：從業(yè)務(wù)服務(wù)是整個(gè)業(yè)務(wù)活動(dòng)的參與方，負(fù)責(zé)提供 TCC 業(yè)務(wù)操作供主業(yè)務(wù)服務(wù)調(diào)用

初步操作 Try：完成所有業(yè)務(wù)檢查，預(yù)留必須的業(yè)務(wù)資源。

確認(rèn)操作 Confirm：真正執(zhí)行的業(yè)務(wù)邏輯，不作任何業(yè)務(wù)檢查，只使用 Try 階段預(yù)留的業(yè)務(wù)資源。因此，只要 Try 操作成功，Confirm 必須能成功。另外，Confirm 操作需滿足冪等性，保證一筆分布式事務(wù)有且只能成功一次。

取消操作 Cancel：釋放 Try 階段預(yù)留的業(yè)務(wù)資源。同樣的，Cancel 操作也需要滿足冪等性。

業(yè)務(wù)活動(dòng)管理器：業(yè)務(wù)活動(dòng)管理器管理控制整個(gè)業(yè)務(wù)活動(dòng)，包括記錄維護(hù) TCC全局事務(wù)的事務(wù)狀態(tài)和每個(gè)從業(yè)務(wù)服務(wù)的子事務(wù)狀態(tài)，并在業(yè)務(wù)活動(dòng)提交時(shí)調(diào)用所有從業(yè)務(wù)服務(wù)的Confirm 操作，在業(yè)務(wù)活動(dòng)取消時(shí)調(diào)用所有從業(yè)務(wù)服務(wù)的Cancel 操作。

2.1.1 TCC 與 XA 對(duì)比 --- 并發(fā)性優(yōu)勢(shì)

TCC把兩階段拆分成了兩個(gè)獨(dú)立的階段，通過(guò)資源業(yè)務(wù)鎖定的方式進(jìn)行關(guān)聯(lián)。資源業(yè)務(wù)鎖定方式的好處在于，既不會(huì)阻塞其他事務(wù)在第一階段對(duì)于相同資源的繼續(xù)使用，也不會(huì)影響本事務(wù)第二階段的正確執(zhí)行。

XA 模型的并發(fā)事務(wù)

TCC 模型的并發(fā)事務(wù)

從上面的對(duì)比可以發(fā)現(xiàn)，TCC模型相比 XA 模型進(jìn)一步減少了資源鎖的持有時(shí)間。XA 模型下，在 Prepare 階段是不會(huì)把事務(wù)1所持有的鎖資源釋放掉的，如果事務(wù)2和事務(wù)1爭(zhēng)搶同一個(gè)資源，事務(wù)2必須等事務(wù)1結(jié)束之后才能使用該資源。

而在TCC里，因?yàn)槭聞?wù)1在Try階段已經(jīng)提交了，那么事務(wù)2可以獲得互斥資源，不必再等待事務(wù)1的Confirm或Cancel階段執(zhí)行完。也就是說(shuō)，事務(wù)2的Try階段可以和事務(wù)1的Confirm或Cancel階段并行執(zhí)行，從而獲得了一個(gè)比較大的并發(fā)性能提升。

2.2 保證大規(guī)模交易下的并發(fā)性能：極致性能優(yōu)化

2010年開始，每年天貓雙十一大促的峰值交易量成倍增加，如下圖所示：

折線上的點(diǎn)代表著每一年的交易峰值（TPS）。前面講過(guò)，每次分布式事務(wù)需要協(xié)調(diào)多個(gè)參與方，因此，每年交易峰值乘以一個(gè)倍數(shù)才是分布式事務(wù)框架要協(xié)調(diào)最終達(dá)到一致性狀態(tài)的峰值分支事務(wù)數(shù)量。事實(shí)上，對(duì)分布式事務(wù)服務(wù)來(lái)說(shuō)，2017年已經(jīng)達(dá)到每秒百萬(wàn)級(jí)水平。

回顧歷年大促，2013年對(duì)支付寶的交易處理是對(duì)我們挑戰(zhàn)很大的一年，2013年雙11提出的峰值目標(biāo)，按照當(dāng)時(shí)大促準(zhǔn)備的計(jì)算和存儲(chǔ)資源，是無(wú)法完成的，怎么辦？

只能選擇繼續(xù)優(yōu)化事務(wù)框架，讓它盡量少消耗資源，并去獲得一個(gè)更大的性能提升。我們根據(jù) TCC 模型的特點(diǎn)以及日常開發(fā)時(shí)積累的經(jīng)驗(yàn)，針對(duì)性能問(wèn)題，做了以下兩類優(yōu)化。

2.2.1 極致性能優(yōu)化之同庫(kù)模式

之前的業(yè)務(wù)活動(dòng)管理器是一個(gè)單獨(dú)的服務(wù)，每次啟動(dòng)業(yè)務(wù)活動(dòng)、登記業(yè)務(wù)操作、提交或回滾業(yè)務(wù)活動(dòng)等操作都需要與業(yè)務(wù)活動(dòng)管理器交互，并且交互次數(shù)與參與者個(gè)數(shù)成正相關(guān)。

因此，為了追求極限性能，將業(yè)務(wù)活動(dòng)管理器的遠(yuǎn)程存儲(chǔ)替換成本地存儲(chǔ)，如下所示：

減少了RPC的調(diào)用，同時(shí)還會(huì)做一些減少存儲(chǔ)次數(shù)的優(yōu)化，從而獲得性能收益。

通過(guò)這種方式，減少RPC調(diào)用耗時(shí)，大幅降低事務(wù)執(zhí)行時(shí)間。同時(shí)還針對(duì)支付、賬務(wù)等訪問(wèn)頻繁的特殊從業(yè)務(wù)服務(wù)，優(yōu)化處理過(guò)程，不再創(chuàng)建單獨(dú)的分支事務(wù)記錄，而是將這個(gè)信息與主事務(wù)記錄合并，在創(chuàng)建主事務(wù)記錄的同時(shí)，記錄分支事務(wù)，最大程度減少與數(shù)據(jù)庫(kù)的交互次數(shù)，從而獲得更高的性能收益。

下面是同庫(kù)模式優(yōu)化前后的時(shí)序圖對(duì)比：

優(yōu)化前時(shí)序圖

優(yōu)化后時(shí)序圖

其中，綠色方塊表示本地?cái)?shù)據(jù)庫(kù)訪問(wèn)?？梢园l(fā)現(xiàn)，優(yōu)化后減少了：(2+n) 次 PRC 延遲 + 1次數(shù)據(jù)庫(kù)訪問(wèn)延遲（n表示參與者個(gè)數(shù)）。

2.2.2 極致性能優(yōu)化之異步化

從理論上來(lái)說(shuō)，只要業(yè)務(wù)允許，事務(wù)的第二階段什么時(shí)候執(zhí)行都可以，因此資源已經(jīng)被業(yè)務(wù)鎖定，不會(huì)有其他事務(wù)動(dòng)用該事務(wù)鎖定的資源。如下圖所示：

這就是 TCC 分布式事務(wù)模型的二階段異步化功能，各從業(yè)務(wù)服務(wù)的第一階段執(zhí)行成功以后，主業(yè)務(wù)服務(wù)就可以提交完成，框架會(huì)保證正確記錄事務(wù)狀態(tài)，然后再由框架異步的執(zhí)行各從業(yè)務(wù)服務(wù)的第二階段，從而比較完整的詮釋最終一致性。

大促的尖峰時(shí)刻是從零點(diǎn)開始的幾十秒或一分鐘之內(nèi)，在這個(gè)時(shí)刻的交易，我們會(huì)把二階段的操作從同步轉(zhuǎn)成異步，在沖高的那一刻，二階段就停止了，一階段正?？劭?，等著交易零點(diǎn)三十分或者夜里一點(diǎn)開始回落的時(shí)候，我們才開始打開二階段，集中做二階段的動(dòng)作。

優(yōu)化后，Confirm 階段在空閑時(shí)段異步執(zhí)行：

假設(shè) Confirm 階段與 Try 階段耗時(shí)相同，單個(gè)事務(wù)耗時(shí)減少50%

數(shù)據(jù)庫(kù)資源消耗減少50%

三. 關(guān)鍵設(shè)計(jì)考量：無(wú)侵入自動(dòng)化的接入體驗(yàn)

眾所周知，螞蟻金服在近幾年除了支付業(yè)務(wù)以外，還發(fā)展出了很多復(fù)雜的金融業(yè)務(wù)，比如財(cái)富、保險(xiǎn)、銀行等。同時(shí)，在2014年螞蟻金服全面開啟了金融云時(shí)代，也會(huì)對(duì)外賦能合作方和客戶。在這些新的場(chǎng)景下面，分布式事務(wù)產(chǎn)品面臨新的挑戰(zhàn)，客戶的性能需求可能不像螞蟻金服內(nèi)部要求那么高，而是更關(guān)注接入的便利性和通用性，要求簡(jiǎn)單易用，對(duì)業(yè)務(wù)代碼無(wú)侵入。因此，分布式事務(wù)產(chǎn)品開始全面升級(jí)，滿足更多客戶對(duì)云端產(chǎn)品的需求。

3.1 框架托管FMT（Framework-managed transactions）模型

TCC 模型作用于業(yè)務(wù)層，負(fù)責(zé)協(xié)調(diào)從業(yè)務(wù)服務(wù)的最終一致性。所有被納入到分布式事務(wù)的從業(yè)務(wù)服務(wù)，需要為框架提供Try、Confirm、Cancel三個(gè)方法，并且需要滿足冪等性。由于方法實(shí)現(xiàn)和要滿足的約束條件都需要業(yè)務(wù)方提供，這無(wú)疑就大大提高了接入門檻。所以我們?cè)赥CC 模型上繼續(xù)往前推進(jìn)發(fā)展，提出了FMT 模型來(lái)解決接入便捷性的問(wèn)題。

FMT 分布式事務(wù)模型與 TCC 模型類似，也同樣包含主業(yè)務(wù)服務(wù)、從業(yè)務(wù)服務(wù)、業(yè)務(wù)活動(dòng)管理器，如下所示：

不同的是，從業(yè)務(wù)服務(wù)不再需要提供 Try、Confirm、Cancel三個(gè)方法，而是直接按照 JDBC 標(biāo)準(zhǔn)，通過(guò)托管框架與底層數(shù)據(jù)庫(kù)交互，就像使用普通數(shù)據(jù)源一樣。托管框架對(duì)業(yè)務(wù)來(lái)說(shuō)是透明的，主要負(fù)責(zé)解析SQL語(yǔ)義，自動(dòng)生成兩階段操作。

3.2 FMT 模型實(shí)現(xiàn)原理

托管框架的兩階段操作如下圖所示：

FMT 框架要求從業(yè)務(wù)服務(wù)只需要正常執(zhí)行SQL操作就可以了，框架會(huì)把業(yè)務(wù)的本地事務(wù)操作作為第一階段。在第一階段，框架會(huì)攔截用戶SQL，解析SQL語(yǔ)義，然后把業(yè)務(wù)SQL涉及數(shù)據(jù)執(zhí)行前后的狀態(tài)保存下來(lái)，即數(shù)據(jù)快照，這個(gè)就相當(dāng)于在邏輯上完成了數(shù)據(jù)庫(kù)內(nèi)的undo和redo操作。在第二階段，如果這個(gè)事務(wù)要提交，那么框架直接把快照數(shù)據(jù)刪除就可以了，因?yàn)榈谝浑A段的正常操作已經(jīng)執(zhí)行完成。如果該事務(wù)要回滾，那么會(huì)先校驗(yàn)臟寫，根據(jù)第一階段保存的執(zhí)行后的快照，檢查在本事務(wù)執(zhí)行過(guò)程中，數(shù)據(jù)有沒有被其他操作修改，如果沒有，則把數(shù)據(jù)執(zhí)行前的快照拿出來(lái)，完成回滾操作。

3.3 一階段示例

舉個(gè)例子，上圖左邊這張表有兩列，一列是賬號(hào)，另一列是金額。這時(shí)如果要針對(duì)該賬戶執(zhí)行一條update操作，框架會(huì)怎么做呢？

在update之前，會(huì)先把賬戶的金額保存下來(lái)，執(zhí)行update操作，然后把執(zhí)行之后的金額保存下來(lái)。因?yàn)樵诙A段有可能會(huì)是回滾操作，回滾的時(shí)候如果想把執(zhí)行之前的數(shù)據(jù)覆蓋回去的話，必須要保證在覆蓋的那個(gè)時(shí)刻，這些行上面的數(shù)據(jù)沒有被別人變更過(guò)，所以最后會(huì)加一個(gè)邏輯行鎖，這個(gè)就是金融系統(tǒng)的特性需求。

3.4 與數(shù)據(jù)訪問(wèn)代理集成

為了更加簡(jiǎn)化云上用戶接入，我們繼續(xù)和內(nèi)部產(chǎn)品數(shù)據(jù)訪問(wèn)代理DBP合作集成，如下所示：

分布式事務(wù)產(chǎn)品框架可以認(rèn)為是被集成在數(shù)據(jù)訪問(wèn)代理里，當(dāng)進(jìn)行一個(gè)事務(wù)時(shí)，上層業(yè)務(wù)方對(duì)于底下的分布式事務(wù)和本地事務(wù)是一視同仁的，通過(guò)數(shù)據(jù)代理看一個(gè)事務(wù)，并執(zhí)行SQL。如果是分布式事務(wù)，數(shù)據(jù)訪問(wèn)代理會(huì)通知框架去執(zhí)行前面提到的一系列保證事務(wù)的操作，以保證數(shù)據(jù)的最終一致。

四. 關(guān)鍵設(shè)計(jì)考量：數(shù)據(jù)實(shí)時(shí)一致性、通用性、性能

4.1 XA模型

TCC和FMT兩個(gè)模型都是在最佳實(shí)踐上追求數(shù)據(jù)的最終一致性，而不是實(shí)時(shí)一致性。

我們分析了金融云上的客戶發(fā)現(xiàn)，如果把業(yè)務(wù)模型假定成數(shù)據(jù)最終一致性，那么依然有很多金融客戶不得不做出很大的妥協(xié)和變更，尤其是原有的業(yè)務(wù)組織模型和業(yè)務(wù)邏輯實(shí)現(xiàn)。而且這種妥協(xié)和調(diào)整的工作量是很大的，門檻也是非常高的。

所以我們基于標(biāo)準(zhǔn)XA做了一個(gè)XA模型來(lái)滿足客戶對(duì)數(shù)據(jù)實(shí)時(shí)一致性的需求。

原生XA協(xié)議提出至今，大概有10-20的時(shí)間了，但是在工業(yè)界應(yīng)用的歷史和案子都很少。為什么會(huì)這樣呢？我們認(rèn)為最重要的一點(diǎn)就是在追求數(shù)據(jù)實(shí)時(shí)一致性的同時(shí)，性能損失太大了。主要有兩個(gè)比較方面的性能損失，一個(gè)是讀和寫之間的沖突，另一個(gè)是寫與寫之間的沖突。

4.2 標(biāo)準(zhǔn)XA問(wèn)題分析

了解數(shù)據(jù)庫(kù)內(nèi)核的人都清楚，數(shù)據(jù)庫(kù)內(nèi)部解決寫和非加鎖讀的沖突是通過(guò)MVCC機(jī)制來(lái)實(shí)現(xiàn)的。假如說(shuō)最新的數(shù)據(jù)塊在更新的同時(shí)，你的讀是可以讀正在更新的數(shù)據(jù)塊的上一個(gè)快照。但是在分布式架構(gòu)下，單機(jī) MVCC 機(jī)制并不能滿足數(shù)據(jù)實(shí)時(shí)性一致性要求。

依然是轉(zhuǎn)賬業(yè)務(wù)場(chǎng)景，A 賬戶給 B 賬務(wù)轉(zhuǎn)賬10塊錢。但是 A 賬戶和 B賬戶分別在兩個(gè)數(shù)據(jù)庫(kù)分片 DB1 和 DB2 上。其操作執(zhí)行過(guò)程如下所以：

如上圖所示，DB1 的本地子事務(wù)已經(jīng)提交完畢，但是 DB2 的本地子事務(wù)還沒提交，這個(gè)時(shí)候只能讀到 DB1 上子事務(wù)執(zhí)行的內(nèi)容，讀不到 DB2 上的子事務(wù)。也就是說(shuō)，雖然在單個(gè) DB 上的本地事務(wù)是實(shí)時(shí)一致的，但是從全局來(lái)看，一個(gè)全局事務(wù)執(zhí)行過(guò)程的中間狀態(tài)被觀察到了，全局實(shí)時(shí)一致性就被破壞了。

但是原生的 XA 協(xié)議沒有規(guī)定快照讀這個(gè)概念，也就沒有定義怎么實(shí)現(xiàn)全局實(shí)時(shí)一致性。最簡(jiǎn)單的做法就是使用串行化的隔離級(jí)別，即使是快照讀也需要轉(zhuǎn)換為加鎖讀，從而來(lái)保證分布式事務(wù)的實(shí)時(shí)一致性。

當(dāng)然，由于串行化隔離級(jí)別的性能較差，很多分布式數(shù)據(jù)庫(kù)都自己實(shí)現(xiàn)了分布式MVCC 機(jī)制來(lái)提供全局的實(shí)時(shí)一致性讀。一個(gè)基本思路是用一個(gè)集中式或者邏輯上單調(diào)遞增的東西來(lái)控制生成全局快照（Snapshot），每個(gè)事務(wù)或者每條 SQL 執(zhí)行時(shí)都去獲取一次，從而實(shí)現(xiàn)不同隔離級(jí)別下的全局一致性,如下圖所示：

在 DB1 的本地子事務(wù)已經(jīng)提交完畢，DB2 的本地子事務(wù)還沒提交的中間狀態(tài)，其他并發(fā)事務(wù)只能看到該事務(wù)執(zhí)行之前的快照。

我們的分布式事務(wù)產(chǎn)品同樣實(shí)現(xiàn)了分布式 MVCC 機(jī)制，從而在保證實(shí)時(shí)一致性的同時(shí)，最大程度的保證讀寫并發(fā)性能。

4.3 并發(fā)寫優(yōu)化 --- 與 OB 深度定制commit 延遲優(yōu)化

除了實(shí)現(xiàn)分布式 MVCC 保證并發(fā)讀寫性能外，我們還與自研數(shù)據(jù)庫(kù) OceanBase 深度定制優(yōu)化并發(fā)寫，進(jìn)一步提升產(chǎn)品性能，共同打造實(shí)時(shí)數(shù)據(jù)一致性的整體解決方案。

傳統(tǒng)標(biāo)準(zhǔn)的二階段提交過(guò)程如下：

其中，綠色方塊表示持久化日志，黃色方塊表示事務(wù)提交。從圖中可以看到，單次Commit 操作需要有3次日志延遲、1次事務(wù)延遲以及2次 RPC 延遲。

OceanBase 內(nèi)部實(shí)現(xiàn)XA協(xié)議的時(shí)候，會(huì)在和協(xié)調(diào)者交互的時(shí)候附帶一些信息，并且在Commit時(shí)落盤，減少Commit過(guò)程中涉及到的RPC和落盤的操作，以達(dá)到減少用戶Commit時(shí)間的效果。

優(yōu)化后時(shí)序圖如下：

雖然在 Commit操作之后，還有 Clear 操作，但是在執(zhí)行 Clear 時(shí)，用戶的Commit請(qǐng)求已經(jīng)返回了，所以并不影響用戶感知的 Commit 請(qǐng)求延遲。因此，從用戶感知的角度來(lái)說(shuō)，單次 Commit 操作實(shí)際上只需要 1次日志延遲、1次事務(wù)延遲 以及 2次RPC延遲。

通過(guò)以上優(yōu)化，兩階段提交與普通提交的落盤次數(shù)和RPC次數(shù)是相同的，也就是說(shuō)耗時(shí)和普通提交相差無(wú)幾，寫和寫之間的沖突所帶來(lái)的額外性能消耗將被降低很大一部分。

五. 總結(jié)

總結(jié)關(guān)于分布式事務(wù)服務(wù)的關(guān)鍵設(shè)計(jì)考量，首先為了保障支付業(yè)務(wù)的核心需求，保障分布式環(huán)境下交易一致性的問(wèn)題，我們基于BASE思想，在業(yè)務(wù)層實(shí)現(xiàn)了TCC 模型，并且為了業(yè)務(wù)發(fā)展的需求，優(yōu)化了其工程實(shí)踐，實(shí)現(xiàn)海量并發(fā)處理能力，讓它的性能可以達(dá)到比業(yè)界其它產(chǎn)品高很多的狀態(tài)。

其次，因?yàn)樯蠈訕I(yè)務(wù)系統(tǒng)的復(fù)雜、業(yè)務(wù)種類的豐富等等業(yè)務(wù)需求，對(duì)分布式事務(wù)解決方案提出了全新的要求，所以我們在TCC模型基礎(chǔ)上又加入了框架托管（FMT）模型，其簡(jiǎn)單易用，對(duì)業(yè)務(wù)無(wú)侵入的特點(diǎn)，可以較好的解決金融云場(chǎng)景下接入便捷性問(wèn)題。

最后，我們對(duì)數(shù)據(jù)實(shí)時(shí)一致性、通用性、性能再思考，與自研數(shù)據(jù)庫(kù) OceanBase 深度定制，推出XA模型，共同打造實(shí)時(shí)數(shù)據(jù)一致性的整體分布式事務(wù)解決方案。

六. 了解更多：金融級(jí)云原生架構(gòu)解決方案SOFA

通過(guò)十多年的探索與實(shí)踐，我們積累了大量的架構(gòu)設(shè)計(jì)原則、最佳實(shí)踐和產(chǎn)品服務(wù)案例，并構(gòu)建了一整套金融級(jí)云原生架構(gòu)解決方案，這套架構(gòu)叫做SOFA（Scalable Open Financial Architecture，分布式事務(wù)DTX亦是其重要的組成部分），源自螞蟻內(nèi)部分布式架構(gòu)實(shí)踐，是一整套完整的金融級(jí)中間件產(chǎn)品技術(shù)和演進(jìn)式架構(gòu)轉(zhuǎn)型服務(wù)體系，已經(jīng)向國(guó)內(nèi)金融機(jī)構(gòu)開放，提供了完整的金融IT基礎(chǔ)架構(gòu)轉(zhuǎn)型量身打造的技術(shù)平臺(tái)和可落地路徑，使業(yè)務(wù)應(yīng)用能專注需求作敏捷交付，又能同時(shí)原生地?fù)碛薪鹑诩?jí)的高可用、一致性特性和互聯(lián)網(wǎng)的海量并發(fā)、彈性伸縮等云原生基礎(chǔ)架構(gòu)能力。