如何分析GTS的原理、架構(gòu)與特點(diǎn)

這期內(nèi)容當(dāng)中小編將會(huì)給大家?guī)?lái)有關(guān)如何分析GTS的原理、架構(gòu)與特點(diǎn)，文章內(nèi)容豐富且以專業(yè)的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

標(biāo)簽

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

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

一、GTS的目標(biāo)

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

制約分布式事務(wù)的三個(gè)因素

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

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

相互制約的三個(gè)因素為：

• 應(yīng)用靈活性：應(yīng)用訪問(wèn)數(shù)據(jù)的方式是否需要修改，以及修改的程度。

• 一致性：數(shù)據(jù)是強(qiáng)一致，還是最終一致的（允許中間不一致的狀態(tài)）。

• 系統(tǒng)性能：分布式事務(wù)對(duì)整體性能的影響。

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

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

XA兩階段提交

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

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

• 步驟1：APP向TM創(chuàng)建全局事務(wù)，TM向APP返回全局事務(wù)號(hào)。

• 步驟2：APP使用全局事務(wù)號(hào)，訪問(wèn)RM的資源（當(dāng)RM為數(shù)據(jù)庫(kù)時(shí)，資源訪問(wèn)就是SQL操作）。當(dāng)RM第一次收到訪問(wèn)時(shí)，使用該全局事務(wù)號(hào)向TM注冊(cè)，TM返回事務(wù)分支事務(wù)號(hào)。

• 步驟3：APP向TM發(fā)出全局事務(wù)提交請(qǐng)求，TM與參與事務(wù)的RM通信，進(jìn)行提交處理，全部完成后，向APP返回結(jié)果。

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

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

可靠消息

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

說(shuō)明：

• 業(yè)務(wù)處理服務(wù)在業(yè)務(wù)事務(wù)提交前，向?qū)崟r(shí)消息服務(wù)請(qǐng)求發(fā)送消息，實(shí)時(shí)消息服務(wù)只記錄消息數(shù)據(jù)，而不真正發(fā)送。

• 業(yè)務(wù)處理服務(wù)在業(yè)務(wù)事務(wù)提交后，向?qū)崟r(shí)消息服務(wù)確認(rèn)發(fā)送。只有在得到確認(rèn)發(fā)送指令后，實(shí)時(shí)消息服務(wù)才真正發(fā)送消息。

• 業(yè)務(wù)處理服務(wù)在業(yè)務(wù)事務(wù)回滾后，向?qū)崟r(shí)消息服務(wù)取消發(fā)送。

• 消息狀態(tài)確認(rèn)系統(tǒng)定期找到未確認(rèn)發(fā)送或回滾發(fā)送的消息，向業(yè)務(wù)處理服務(wù)詢問(wèn)消息狀態(tài)，業(yè)務(wù)處理服務(wù)根據(jù)消息ID或消息內(nèi)容確定該消息是否有效。

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

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

TCC模式

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

說(shuō)明：

• 一個(gè)完整的業(yè)務(wù)活動(dòng)由一個(gè)主業(yè)務(wù)服務(wù)與若干從業(yè)務(wù)服務(wù)組成。

• 主業(yè)務(wù)服務(wù)負(fù)責(zé)發(fā)起并完成整個(gè)業(yè)務(wù)活動(dòng)。

• 從業(yè)務(wù)服務(wù)提供TCC型業(yè)務(wù)操作。

• 業(yè)務(wù)活動(dòng)管理器控制業(yè)務(wù)活動(dòng)的一致性，它登記業(yè)務(wù)活動(dòng)中的操作，并在業(yè)務(wù)活動(dòng)提交時(shí)確認(rèn)所有的TCC型操作的confirm操作，在業(yè)務(wù)活動(dòng)取消時(shí)調(diào)用所有TCC型操作的cancel操作。

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

• 第一階段：主業(yè)務(wù)服務(wù)分別調(diào)用所有從業(yè)務(wù)的 try 操作，并在活動(dòng)管理器中登記所有從業(yè)務(wù)服務(wù)。當(dāng)所有從業(yè)務(wù)服務(wù)的 try 操作都調(diào)用成功或者某個(gè)從業(yè)務(wù)服務(wù)的 try 操作失敗，進(jìn)入第二階段。

• 第二階段：活動(dòng)管理器根據(jù)第一階段的執(zhí)行結(jié)果來(lái)執(zhí)行 confirm 或 cancel 操作。
  如果第一階段所有 try 操作都成功，則活動(dòng)管理器調(diào)用所有從業(yè)務(wù)活動(dòng)的 confirm操作。否則調(diào)用所有從業(yè)務(wù)服務(wù)的 cancel 操作。

小結(jié)

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

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

二、GTS的技術(shù)路線

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

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

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

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

• 第二步數(shù)據(jù)訪問(wèn)中，各事務(wù)分支完成數(shù)據(jù)操作的同時(shí)，會(huì)將全局事務(wù)信息（鎖與日志信息）存儲(chǔ)在當(dāng)前數(shù)據(jù)庫(kù)的表中。

• 第三步全局事務(wù)提交中，采用一階段本地事務(wù)提交+二階段異步清理的方式。首先對(duì)各數(shù)據(jù)庫(kù)做本地事務(wù)的提交，并釋放數(shù)據(jù)庫(kù)連接等系統(tǒng)資源，然后，向TM發(fā)出全局事務(wù)提交請(qǐng)求，TM收到請(qǐng)求后，立即返回成功，TM后續(xù)實(shí)際工作是對(duì)各個(gè)數(shù)據(jù)庫(kù)使用全局事務(wù)標(biāo)識(shí)符進(jìn)行全局事務(wù)信息的清理。

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

• XA兩階段協(xié)議是基于數(shù)據(jù)庫(kù)內(nèi)核的日志與鎖信息實(shí)現(xiàn)全局事務(wù)的回滾與并發(fā)控制。由于GTS一階段本地事務(wù)提交中，會(huì)直接提交本地事務(wù)并釋放連接，此時(shí)數(shù)據(jù)庫(kù)內(nèi)核的日志與鎖表對(duì)全局事務(wù)不再有效。在第二步中，GTS會(huì)將日志和鎖信息存儲(chǔ)在表中，當(dāng)事務(wù)本地提交后，日志和鎖信息被持久化保存，用于實(shí)現(xiàn)全局事務(wù)的并發(fā)控制與故障恢復(fù)。

• GTS的故障恢復(fù)只有UNDO操作沒(méi)有REDO操作，日志表中存儲(chǔ)了UNDO需要的信息，包括行記錄標(biāo)識(shí)、全局事務(wù)號(hào)、鏡像查詢語(yǔ)句、操作的前像與操作的后像。當(dāng)發(fā)生故障時(shí)，對(duì)于已經(jīng)本地提交的數(shù)據(jù)庫(kù)，從UNDO表中找到修改的記錄，記錄的操作前像和操作后像，使用鏡像查詢語(yǔ)句從數(shù)據(jù)庫(kù)中讀取該記錄的當(dāng)前值。如果當(dāng)前值與記錄操作后像相同，則直接使用操作前像進(jìn)行恢復(fù)，否則報(bào)警，進(jìn)行人工處理。

• GTS的全局鎖表中存儲(chǔ)了記錄的加鎖信息。封鎖的粒度是行（記錄），鎖的類型包括共享鎖和互斥鎖，對(duì)于同一個(gè)記錄，加鎖的規(guī)則是共享鎖與共享鎖不沖突，共享鎖與互斥鎖沖突、互斥鎖與互斥鎖沖突。對(duì)插入(INSERT)、修改(UPDATE)、刪除(DELETE)、更新模式的鎖定查詢(SELECT… FOR UPDATE) 操作加互斥鎖。對(duì)于共享模式的鎖定查詢 (SELECT…LOCK IN SHARE MODE) 操作加共享鎖。若沒(méi)有鎖沖突，在GTS鎖表中，增加一行記錄，表示加鎖成功。

• GTS的默認(rèn)隔離級(jí)別為讀未提交（臟數(shù)據(jù)），使用SELECT… FOR UPDATE和SELECT…LOCK IN SHARE MODE，可使查詢隔離級(jí)別提升至讀已提交。

三、GTS的架構(gòu)與處理流程

架構(gòu)

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

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

• 事務(wù)分支處理模塊：是資源管理器的外部接口，并完成內(nèi)部各模塊的調(diào)用。

• 鏡像查詢構(gòu)造模塊：從Insert、Update、Delete語(yǔ)句，生成該操作對(duì)應(yīng)記錄集的鏡像查詢語(yǔ)句。例如table_name表包含兩個(gè)字段column1和column2，column1為主鍵，則鏡像查詢語(yǔ)句為select column1, column2 from table_name where column1=v1。

• 并發(fā)控制模塊：基于GTS事務(wù)鎖表，維護(hù)讀寫并發(fā)控制。鎖表定義如下：

• 恢復(fù)控制模塊：基于GTS日志表，進(jìn)行故障恢復(fù)。 日志表定義如下：

主要流程序列圖

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

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

讀已提交操作流程序列圖

提交操作流程序列圖

回滾操作流程序列圖

阿里官方案例

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

• A和B兩個(gè)用戶的數(shù)據(jù)分別位于一個(gè)DRDS實(shí)例的兩個(gè)不同分庫(kù)中，用50個(gè)進(jìn)程并發(fā)進(jìn)行 A轉(zhuǎn)賬給3，每個(gè)進(jìn)程轉(zhuǎn)賬10次，每次轉(zhuǎn)賬金額在1到10之間隨機(jī)生成，轉(zhuǎn)賬過(guò)程中模擬了3%的網(wǎng)絡(luò)異常，使用GTS事務(wù)保證了A和B錢的總數(shù)不變。

• 從代碼上可看出，只需增加一條開(kāi)啟GTS的sql語(yǔ)句，就將單機(jī)事務(wù)應(yīng)用提升至分布式事務(wù)，體現(xiàn)出很好的應(yīng)用靈活性。測(cè)試中轉(zhuǎn)賬事務(wù)執(zhí)行500次，成功490次，失敗10次。轉(zhuǎn)賬結(jié)束10秒后，查詢賬戶金額總數(shù)正確。

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

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

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

• 靈活性：數(shù)據(jù)庫(kù)應(yīng)用基本實(shí)現(xiàn)零修改，同時(shí)，基于XA模型，可方便的支持消息隊(duì)列數(shù)據(jù)庫(kù)等多種RM。

• 數(shù)據(jù)一致性：GTS 的缺省事務(wù)隔離級(jí)別為讀未提交，該模式下可以達(dá)到分布式事務(wù)的最大性能，但可能會(huì)讀到臟數(shù)據(jù)。對(duì)于一致性要求高的應(yīng)用，在性能允許的情況下，可以采用已提交讀語(yǔ)句（for update、lock in share mode）將隔離級(jí)別提升至讀已提交。

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

上述就是小編為大家分享的如何分析GTS的原理、架構(gòu)與特點(diǎn)了，如果剛好有類似的疑惑，不妨參照上述分析進(jìn)行理解。如果想知道更多相關(guān)知識(shí)，歡迎關(guān)注億速云行業(yè)資訊頻道。