摘要：?全局事務服務（Global Transaction Service，簡稱 GTS）是阿里新推出的分布式事務處理方案，對其深入分析的資料相對匱乏。本文的目標是剖析GTS的技術路線，厘清其優(yōu)勢與約束。

作者

趙成

日期

2018-01-01

標簽

分布式事務 , GTS ， Global Transaction Service, 柔性事務, TCC , XA兩階段提交協(xié)議

---

全局事務服務（Global Transaction Service，簡稱 GTS）是阿里新推出的分布式事務處理方案，對其深入分析的資料相對匱乏。本文的目標是剖析GTS的技術路線，厘清其優(yōu)勢與約束。文章參考了GTS公開的專利、產(chǎn)品文檔、相關網(wǎng)頁，文章中肯定有不準確的地方，歡迎各位同學拍磚與指正。

一、GTS的目標

GTS是一個面向互聯(lián)網(wǎng)交易場景的分布式事務解決方案。

制約分布式事務的三個因素

分布式事務是互聯(lián)網(wǎng)交易場景面臨的關鍵問題之一。不同于搜索、社交、聯(lián)機分析應用，電子商務、支付是典型的交易場景，數(shù)據(jù)的錯誤會帶來嚴重的后果，對數(shù)據(jù)的一致性與可用性有很高的要求。互聯(lián)網(wǎng)環(huán)境帶來了海量的數(shù)據(jù)容量、連接數(shù)與訪問量，單一數(shù)據(jù)庫節(jié)點無法應對，成為整個系統(tǒng)的瓶頸。為解決單一數(shù)據(jù)庫成為瓶頸的問題，通過數(shù)據(jù)拆分實現(xiàn)數(shù)據(jù)庫能力的線性擴展。數(shù)據(jù)拆分是使用分庫分表的方式，將數(shù)據(jù)存儲在多個數(shù)據(jù)庫節(jié)點，利用分布式數(shù)據(jù)庫平臺解決數(shù)據(jù)庫瓶頸的問題。分布式數(shù)據(jù)庫環(huán)境中，一個事務會跨越多個數(shù)據(jù)庫，面臨分布式事務處理的問題。

分布式事務解決方案面臨應用靈活性、數(shù)據(jù)一致性、性能三者的挑戰(zhàn)。目前已有多種成熟方案，每種方案都是對這三個方面做出的取舍。

相互制約的三個因素為：

• 應用靈活性：應用訪問數(shù)據(jù)的方式是否需要修改，以及修改的程度。
• 一致性：數(shù)據(jù)是強一致，還是最終一致的（允許中間不一致的狀態(tài)）。
• 系統(tǒng)性能：分布式事務對整體性能的影響。

現(xiàn)有分布式處理方案

現(xiàn)有成熟的分布式解決方案包括XA兩階段提交、可靠消息與TCC模式等類型。XA兩階段提交屬于強一致事務，可靠消息與TCC模式屬于柔性事務。

XA兩階段提交

XA 是指由 X/Open 組織提出的分布式事務處理的規(guī)范。XA規(guī)范主要定義了Transaction Manager（TM）和Resource Manager（RM）之間的接口，結(jié)構如下圖所示。

?

XA協(xié)議的流程可大致分為三個步驟：

• 步驟1：APP向TM創(chuàng)建全局事務，TM向APP返回全局事務號。
• 步驟2：APP使用全局事務號，訪問RM的資源（當RM為數(shù)據(jù)庫時，資源訪問就是SQL操作）。當RM第一次收到訪問時，使用該全局事務號向TM注冊，TM返回事務分支事務號。
• 步驟3：APP向TM發(fā)出全局事務提交請求，TM與參與事務的RM通信，進行提交處理，全部完成后，向APP返回結(jié)果。

TM與RM之間的提交處理，采用兩階段提交協(xié)議。TM在第一階段對所有的參與事務的RM請求“預備”操作，達成關于分布式事務一致性的共識。事務參與者必須完成所有的約束檢查，并且確保后續(xù)提交或放棄時所需要的數(shù)據(jù)已持久化。在第二階段，根據(jù)之前達到的提交或放棄的共識，請求所有參事務的RM完成相應的操作。

提交事務的過程中需要在多個資源節(jié)點之間進行協(xié)調(diào)，而各節(jié)點對鎖資源的釋放必須等到事務最終提交時，所以兩階段提交在執(zhí)行同樣的事務時會比一階段提交消耗更多的時間。當事務并發(fā)量達到一定數(shù)量時，就會出現(xiàn)大量事務積壓甚至出現(xiàn)死鎖，系統(tǒng)性能和處理吞吐量就會嚴重下滑。

可靠消息

可靠消息的一種可能實現(xiàn)的結(jié)構如下圖。

?

說明：

• 業(yè)務處理服務在業(yè)務事務提交前，向?qū)崟r消息服務請求發(fā)送消息，實時消息服務只記錄消息數(shù)據(jù)，而不真正發(fā)送。
• 業(yè)務處理服務在業(yè)務事務提交后，向?qū)崟r消息服務確認發(fā)送。只有在得到確認發(fā)送指令后，實時消息服務才真正發(fā)送消息。
• 業(yè)務處理服務在業(yè)務事務回滾后，向?qū)崟r消息服務取消發(fā)送。
• 消息狀態(tài)確認系統(tǒng)定期找到未確認發(fā)送或回滾發(fā)送的消息，向業(yè)務處理服務詢問消息狀態(tài)，業(yè)務處理服務根據(jù)消息ID或消息內(nèi)容確定該消息是否有效。

通過消息進行事務異步的方式，可以保證業(yè)務數(shù)據(jù)操作和消息的發(fā)送同時執(zhí)行成功或失敗，保持了事務的最終一致性。

采用可靠消息的方式，在兩個事務間實現(xiàn)分布式事務時，可以很好地滿足事務最終一致性以及事務的回滾，但如果一個事務上下文中超過兩個事務操作后，需要開發(fā)人員實現(xiàn)整個事務流程的操作日志的記錄、每個事務分支的回滾以及整個流程的準確調(diào)度。

TCC模式

TCC模式為全局事務執(zhí)行提供了一個框架，開發(fā)人員只需要實現(xiàn)每個事務分支的回滾，不需要記錄整個事務流程的操作日志。TCC模式結(jié)構如下圖。

?

說明：

• 一個完整的業(yè)務活動由一個主業(yè)務服務與若干從業(yè)務服務組成。
• 主業(yè)務服務負責發(fā)起并完成整個業(yè)務活動。
• 從業(yè)務服務提供TCC型業(yè)務操作。
• 業(yè)務活動管理器控制業(yè)務活動的一致性，它登記業(yè)務活動中的操作，并在業(yè)務活動提交時確認所有的TCC型操作的confirm操作，在業(yè)務活動取消時調(diào)用所有TCC型操作的cancel操作。

TCC業(yè)務包括兩個階段完成：

• 第一階段：主業(yè)務服務分別調(diào)用所有從業(yè)務的 try 操作，并在活動管理器中登記所有從業(yè)務服務。當所有從業(yè)務服務的 try 操作都調(diào)用成功或者某個從業(yè)務服務的 try 操作失敗，進入第二階段。
• 第二階段：活動管理器根據(jù)第一階段的執(zhí)行結(jié)果來執(zhí)行 confirm 或 cancel 操作。
  如果第一階段所有 try 操作都成功，則活動管理器調(diào)用所有從業(yè)務活動的 confirm操作。否則調(diào)用所有從業(yè)務服務的 cancel 操作。

小結(jié)

可靠消息與TCC模式通過避免XA兩階段提交對數(shù)據(jù)資源的長期鎖定提升了性能，通過在數(shù)據(jù)庫外部實現(xiàn)事務機制達到了最終一致性，但犧牲了應用靈活性，需要開發(fā)人員實現(xiàn)事務檢查與回滾的細節(jié)，面臨著花費大量精力保證應用正確性的問題。

GTS目標是在性能開銷可接受的情況下，由GTS統(tǒng)一處理全局事務的故障恢復與并發(fā)控制，對應用開發(fā)屏蔽事務處理的細節(jié)，從而提升應用的靈活性與數(shù)據(jù)的一致性。

二、GTS的技術路線

GTS采用基于XA架構優(yōu)化的技術路線，在保留XA架構靈活性的優(yōu)點下，通過將XA提交中的第一階段與第二階段解耦，將提交過程轉(zhuǎn)換為第一階段本地事務提交+第二階段異步清理的方式，從而提供提升系統(tǒng)性能，同時通過在GTS內(nèi)部維護應用級別的日志與鎖信息，實現(xiàn)了全局事務的回滾與并發(fā)控制。

GTS方案認為XA性能低效的根本原因是采用了阻塞協(xié)議。在分布式事務提交的第一階段等待最慢的一個事務分支完成，即使在不存在鎖沖突的情況下，各事務分支的數(shù)據(jù)庫連接依然會被掛起所占用的資源都不能夠釋放，以防止全局事務提交前釋放資源所造成的數(shù)據(jù)不一致。對于業(yè)務流量極高的大規(guī)模互聯(lián)網(wǎng)企業(yè)，難以接受 XA 兩階段提交協(xié)議所帶來的巨大性能開銷。

GTS架構包含的組件與XA完全相同，示意架構如下圖。

?

GTS全局事務處理流程與XA一致，也包括全局事務注冊、數(shù)據(jù)訪問與全局事務提交三個步驟，但在第二步與第三步的內(nèi)部處理上與XA不同：

• 第二步數(shù)據(jù)訪問中，各事務分支完成數(shù)據(jù)操作的同時，會將全局事務信息（鎖與日志信息）存儲在當前數(shù)據(jù)庫的表中。
• 第三步全局事務提交中，采用一階段本地事務提交+二階段異步清理的方式。首先對各數(shù)據(jù)庫做本地事務的提交，并釋放數(shù)據(jù)庫連接等系統(tǒng)資源，然后，向TM發(fā)出全局事務提交請求，TM收到請求后，立即返回成功，TM后續(xù)實際工作是對各個數(shù)據(jù)庫使用全局事務標識符進行全局事務信息的清理。

GTS與XA在全局事務的故障恢復處理與并發(fā)控制采用了不同的實現(xiàn)機制：

• XA兩階段協(xié)議是基于數(shù)據(jù)庫內(nèi)核的日志與鎖信息實現(xiàn)全局事務的回滾與并發(fā)控制。由于GTS一階段本地事務提交中，會直接提交本地事務并釋放連接，此時數(shù)據(jù)庫內(nèi)核的日志與鎖表對全局事務不再有效。在第二步中，GTS會將日志和鎖信息存儲在表中，當事務本地提交后，日志和鎖信息被持久化保存，用于實現(xiàn)全局事務的并發(fā)控制與故障恢復。
• GTS的故障恢復只有UNDO操作沒有REDO操作，日志表中存儲了UNDO需要的信息，包括行記錄標識、全局事務號、鏡像查詢語句、操作的前像與操作的后像。當發(fā)生故障時，對于已經(jīng)本地提交的數(shù)據(jù)庫，從UNDO表中找到修改的記錄，記錄的操作前像和操作后像，使用鏡像查詢語句從數(shù)據(jù)庫中讀取該記錄的當前值。如果當前值與記錄操作后像相同，則直接使用操作前像進行恢復，否則報警，進行人工處理。
• GTS的全局鎖表中存儲了記錄的加鎖信息。封鎖的粒度是行（記錄），鎖的類型包括共享鎖和互斥鎖，對于同一個記錄，加鎖的規(guī)則是共享鎖與共享鎖不沖突，共享鎖與互斥鎖沖突、互斥鎖與互斥鎖沖突。對插入(INSERT)、修改(UPDATE)、刪除(DELETE)、更新模式的鎖定查詢(SELECT… FOR UPDATE) 操作加互斥鎖。對于共享模式的鎖定查詢 (SELECT…LOCK IN SHARE MODE) 操作加共享鎖。若沒有鎖沖突，在GTS鎖表中，增加一行記錄，表示加鎖成功。
• GTS的默認隔離級別為讀未提交（臟數(shù)據(jù)），使用SELECT… FOR UPDATE和SELECT…LOCK IN SHARE MODE，可使查詢隔離級別提升至讀已提交。

三、GTS的架構與處理流程

架構

下圖描述了GTS一種可能的實現(xiàn)架構。

?

與XA架構相同，GTS架構由應用、事務管理器、資源管理器三個部分組成。資源管理器由事務分支處理模塊、鏡像查詢構造模塊、并發(fā)控制模塊、恢復控制模塊，以及存儲在數(shù)據(jù)庫中的GTS事務信息（GTS鎖表與GTS日志表）等組成。

• 事務分支處理模塊：是資源管理器的外部接口，并完成內(nèi)部各模塊的調(diào)用。
• 鏡像查詢構造模塊：從Insert、Update、Delete語句，生成該操作對應記錄集的鏡像查詢語句。例如table_name表包含兩個字段column1和column2，column1為主鍵，則鏡像查詢語句為select column1, column2 from table_name where column1=v1。
• 并發(fā)控制模塊：基于GTS事務鎖表，維護讀寫并發(fā)控制。鎖表定義如下：

字段名字段類型字段描述

ID	整數(shù)	自增主鍵
TABLE_NAME	字符串	表名
KEY_VALUE	整數(shù)	數(shù)據(jù)行ID
XID	字符串	全局事務標識
XLOCK	整數(shù)	互斥鎖標記
SLOCK	整數(shù)	共享鎖標記
BRANCH_ID	整數(shù)	事務分支標識

• 恢復控制模塊：基于GTS日志表，進行故障恢復。 日志表定義如下：

字段名字段類型字段描述

ID	整數(shù)	自增主鍵
GMT_CREATE	時間	創(chuàng)建時間
GMT_MODIFIED	datetime	修改時間
XID	整數(shù)	全局事務ID
BRANCH_ID	整數(shù)	分支事務ID
ROLLBACK_INFO	longblob	查詢語句、前像與后像
STATUS	整數(shù)	狀態(tài)
SERVER	字符串	分支所在DB IP

主要流程序列圖

分別描述了insert/delete/update操作、讀已提交操作、提交操作和回滾操作等四個操作的序列圖（一種可能的實現(xiàn)方式）。

insert/delete/update操作流程序列圖

?

讀已提交操作流程序列圖

?

提交操作流程序列圖

?

回滾操作流程序列圖

?

阿里官方案例

GTS產(chǎn)品網(wǎng)站給出了一個交易類事務中最典型的轉(zhuǎn)賬案例

• A和B兩個用戶的數(shù)據(jù)分別位于一個DRDS實例的兩個不同分庫中，用50個進程并發(fā)進行 A轉(zhuǎn)賬給3，每個進程轉(zhuǎn)賬10次，每次轉(zhuǎn)賬金額在1到10之間隨機生成，轉(zhuǎn)賬過程中模擬了3%的網(wǎng)絡異常，使用GTS事務保證了A和B錢的總數(shù)不變。
• 從代碼上可看出，只需增加一條開啟GTS的sql語句，就將單機事務應用提升至分布式事務，體現(xiàn)出很好的應用靈活性。測試中轉(zhuǎn)賬事務執(zhí)行500次，成功490次，失敗10次。轉(zhuǎn)賬結(jié)束10秒后，查詢賬戶金額總數(shù)正確。

2017云棲大會 GTS產(chǎn)品介紹中，給出了使用GTS與不使用事務（1PC）測試對比。下圖，GTS比1PC的性能損耗在10%，遠遠小于2PC方式，表現(xiàn)出優(yōu)異的性能。

四、GTS的優(yōu)勢與約束

與基于消息隊列與TCC補償模式的分布式事務相比，在性能滿足的情況下，GTS更好的應用靈活性與數(shù)據(jù)一致性：

• 靈活性：數(shù)據(jù)庫應用基本實現(xiàn)零修改，同時，基于XA模型，可方便的支持消息隊列數(shù)據(jù)庫等多種RM。
• 數(shù)據(jù)一致性：GTS 的缺省事務隔離級別為讀未提交，該模式下可以達到分布式事務的最大性能，但可能會讀到臟數(shù)據(jù)。對于一致性要求高的應用，在性能允許的情況下，可以采用已提交讀語句（for update、lock in share mode）將隔離級別提升至讀已提交。

根據(jù)GTS實現(xiàn)機制的特點，其應用場景上有以下約束：加鎖操作記錄數(shù)量不能太大，操作沖突不能太多，加鎖時間不能太長。違法以上約束時，GTS內(nèi)部會占用過多資源、鎖沖突和回滾增加，導致性能的下降。電商、物流、金融、零售行業(yè)中的核心交易場景有著高并發(fā)，高性能，單次操作數(shù)據(jù)集小，事務響應時間敏感的特點，GTS類方案在此類場景中有著廣泛和良好的應用前景。

五、參考

書

• 《企業(yè)IT架構轉(zhuǎn)型之道》第六章

專利

• CN201510111872-一種分布式事務處理方法及系統(tǒng)
• CN201510111986-一種分布式事務處理方法及系統(tǒng)

網(wǎng)頁

• 破解世界性技術難題！ GTS讓分布式事務簡單高效
• 分布式事務云市場分析
• 分布式事務中間件GTS（TXC）
• GTS for DRDS分布式事務的實現(xiàn)理解
• GTS全局事務測試－單DRDS跨庫事務

---

版權聲明：自由轉(zhuǎn)載-非商用-非衍生-保持署名（創(chuàng)意共享3.0許可證）

from:?https://yq.aliyun.com/articles/334238?

總結(jié)

以上是生活随笔為你收集整理的阿里GTS解密--GTS的原理、架构与特点的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。