如何進行分布式事務框架GTS全解析

今天就跟大家聊聊有關如何進行分布式事務框架GTS全解析，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結了以下內容，希望大家根據這篇文章可以有所收獲。

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

一、GTS的目標

GTS是一個面向互聯網交易場景的分布式事務解決方案。

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

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

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

相互制約的三個因素為：

• 應用靈活性：應用訪問數據的方式是否需要修改，以及修改的程度。

• 一致性：數據是強一致，還是最終一致的（允許中間不一致的狀態）。

• 系統性能：分布式事務對整體性能的影響。

現有分布式處理方案

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

XA兩階段提交

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

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

• 步驟1：APP向TM創建全局事務，TM向APP返回全局事務號。

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

• 步驟3：APP向TM發出全局事務提交請求，TM與參與事務的RM通信，進行提交處理，全部完成后，向APP返回結果。

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

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

可靠消息

可靠消息的一種可能實現的結構如下圖。

說明：

• 業務處理服務在業務事務提交前，向實時消息服務請求發送消息，實時消息服務只記錄消息數據，而不真正發送。

• 業務處理服務在業務事務提交后，向實時消息服務確認發送。只有在得到確認發送指令后，實時消息服務才真正發送消息。

• 業務處理服務在業務事務回滾后，向實時消息服務取消發送。

• 消息狀態確認系統定期找到未確認發送或回滾發送的消息，向業務處理服務詢問消息狀態，業務處理服務根據消息ID或消息內容確定該消息是否有效。

通過消息進行事務異步的方式，可以保證業務數據操作和消息的發送同時執行成功或失敗，保持了事務的最終一致性。

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

TCC模式

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

說明：

• 一個完整的業務活動由一個主業務服務與若干從業務服務組成。

• 主業務服務負責發起并完成整個業務活動。

• 從業務服務提供TCC型業務操作。

• 業務活動管理器控制業務活動的一致性，它登記業務活動中的操作，并在業務活動提交時確認所有的TCC型操作的confirm操作，在業務活動取消時調用所有TCC型操作的cancel操作。

TCC業務包括兩個階段完成：

• 第一階段：主業務服務分別調用所有從業務的 try 操作，并在活動管理器中登記所有從業務服務。當所有從業務服務的 try 操作都調用成功或者某個從業務服務的 try 操作失敗，進入第二階段。

• 第二階段：活動管理器根據第一階段的執行結果來執行 confirm 或 cancel 操作。如果第一階段所有 try 操作都成功，則活動管理器調用所有從業務活動的 confirm操作。否則調用所有從業務服務的 cancel 操作。

小結

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

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

二、GTS的技術路線

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

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

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

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

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

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

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

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

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

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

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

三、GTS的架構與處理流程

架構

下圖描述了GTS一種可能的實現架構。

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

• 事務分支處理模塊：是資源管理器的外部接口，并完成內部各模塊的調用。

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

• 并發控制模塊：基于GTS事務鎖表，維護讀寫并發控制。鎖表定義如下：

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

主要流程序列圖

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

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

讀已提交操作流程序列圖

提交操作流程序列圖

回滾操作流程序列圖

阿里官方案例

GTS產品網站給出了一個交易類事務中最典型的[轉賬案例](GTS全局事務測試－單DRDS跨庫事務-博客-云棲社區-阿里云)

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

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

2017云棲大會 GTS產品介紹中，給出了使用GTS與不使用事務（1PC）[測試對比](破解世界性技術難題！ GTS讓分布式事務簡單高效)。下圖，GTS比1PC的性能損耗在10%，遠遠小于2PC方式，表現出優異的性能。

四、GTS的優勢與約束

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

• 靈活性：數據庫應用基本實現零修改，同時，基于XA模型，可方便的支持消息隊列數據庫等多種RM。

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

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

看完上述內容，你們對如何進行分布式事務框架GTS全解析有進一步的了解嗎？如果還想了解更多知識或者相關內容，請關注億速云行業資訊頻道，感謝大家的支持。