標籤
分佈式事務 , GTS ， Global Transaction Service, 柔性事務, TCC , XA兩階段提交協議
全局事務服務（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事務鎖表，維護讀寫併發控制。鎖表定義如下：
| 字段名 | 字段類型 | 字段描述 |
|---|---|---|
| ID | 整數 | 自增主鍵 |
| TABLE_NAME | 字符串 | 表名 |
| KEY_VALUE | 整數 | 數據行ID |
| XID | 字符串 | 全局事務標識 |
| XLOCK | 整數 | 互斥鎖標記 |
| SLOCK | 整數 | 共享鎖標記 |
| BRANCH_ID | 整數 | 事務分支標識 |
- 恢復控制模塊：基於GTS日誌表，進行故障恢復。 日誌表定義如下：
| 字段名 | 字段類型 | 字段描述 |
|---|---|---|
| ID | 整數 | 自增主鍵 |
| GMT_CREATE | 時間 | 創建時間 |
| GMT_MODIFIED | datetime | 修改時間 |
| XID | 整數 | 全局事務ID |
| BRANCH_ID | 整數 | 分支事務ID |
| ROLLBACK_INFO | longblob | 查詢語句、前像與後像 |
| STATUS | 整數 | 狀態 |
| SERVER | 字符串 | 分支所在DB IP |
主要流程序列圖
分別描述了insert/delete/update操作、讀已提交操作、提交操作和回滾操作等四個操作的序列圖（一種可能的實現方式）。
insert/delete/update操作流程序列圖
讀已提交操作流程序列圖
提交操作流程序列圖
回滾操作流程序列圖
阿里官方案例
GTS產品網站給出了一個交易類事務中最典型的轉賬案例
- A和B兩個用戶的數據分別位於一個DRDS實例的兩個不同分庫中，用50個進程併發進行 A轉賬給3，每個進程轉賬10次，每次轉賬金額在1到10之間隨機生成，轉賬過程中模擬了3%的網絡異常，使用GTS事務保證了A和B錢的總數不變。
- 從代碼上可看出，只需增加一條開啓GTS的sql語句，就將單機事務應用提升至分佈式事務，體現出很好的應用靈活性。測試中轉賬事務執行500次，成功490次，失敗10次。轉賬結束10秒後，查詢賬戶金額總數正確。
2017雲棲大會 GTS產品介紹中，給出了使用GTS與不使用事務（1PC）測試對比。下圖，GTS比1PC的性能損耗在10%，遠遠小於2PC方式，表現出優異的性能。
四、GTS的優勢與約束
與基於消息隊列與TCC補償模式的分佈式事務相比，在性能滿足的情況下，GTS更好的應用靈活性與數據一致性：
- 靈活性：數據庫應用基本實現零修改，同時，基於XA模型，可方便的支持消息隊列數據庫等多種RM。
- 數據一致性：GTS 的缺省事務隔離級別爲讀未提交，該模式下可以達到分佈式事務的最大性能，但可能會讀到髒數據。對於一致性要求高的應用，在性能允許的情況下，可以採用已提交讀語句（for update、lock in share mode）將隔離級別提升至讀已提交。
根據GTS實現機制的特點，其應用場景上有以下約束：加鎖操作記錄數量不能太大，操作衝突不能太多，加鎖時間不能太長。違法以上約束時，GTS內部會佔用過多資源、鎖衝突和回滾增加，導致性能的下降。電商、物流、金融、零售行業中的核心交易場景有着高併發，高性能，單次操作數據集小，事務響應時間敏感的特點，GTS類方案在此類場景中有着廣泛和良好的應用前景。
五、參考
書
- 《企業IT架構轉型之道》第六章
專利
- CN201510111872-一種分佈式事務處理方法及系統
- CN201510111986-一種分佈式事務處理方法及系統
網頁
