阿里分散式事務框架 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類方案在此類場景中有著廣泛和良好的應用前景。