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

創(chuàng)新互聯(lián)建站專注于鎮(zhèn)平網(wǎng)站建設(shè)服務(wù)及定制，我們擁有豐富的企業(yè)做網(wǎng)站經(jīng)驗。 熱誠為您提供鎮(zhèn)平營銷型網(wǎng)站建設(shè)，鎮(zhèn)平網(wǎng)站制作、鎮(zhèn)平網(wǎng)頁設(shè)計、鎮(zhèn)平網(wǎng)站官網(wǎng)定制、小程序設(shè)計服務(wù)，打造鎮(zhèn)平網(wǎng)絡(luò)公司原創(chuàng)品牌,更為您提供鎮(zhèn)平網(wǎng)站排名全網(wǎng)營銷落地服務(wù)。

標(biāo)簽

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

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

一、GTS的目標(biāo)

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

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

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

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

相互制約的三個因素為：

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

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

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

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

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

XA兩階段提交

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

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

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

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

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

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

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

可靠消息

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

說明：

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

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

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

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

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

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

TCC模式

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

說明：

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

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

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

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

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

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

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

小結(jié)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

架構(gòu)

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

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

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

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

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

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

主要流程序列圖

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

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

讀已提交操作流程序列圖

提交操作流程序列圖

回滾操作流程序列圖

阿里官方案例

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

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

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

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

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

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

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

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

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

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