分布式事務 GTS 的價值和原理淺析

GTS 今年雙 11 的成績

今年 2684 億的背后，有一個默默支撐，低調到幾乎被遺忘的中間件雲產品——GTS（全局事務服務，Global Transaction Service），穩穩地通過了自 2014 年誕生以來的第 5 次“大考”。

2019 年 11 月 1 日至 12 日，GTS 日均處理分布式事務數量達 億級 ，每天峰值 TPS 達 萬級 。

這背后最重要意義在於：成績是在給業務應用的設計和開發帶來 0 負擔 的前提下得到的。

GTS 帶來的價值

隨着企業的發展，企業業務架構面臨數據、服務的分布化，幾乎無可避免地要遇到分布式架構帶來的數據一致性問題。

GTS 開創性地把分布式事務問題從業務中剝離出來，作為一個獨立的技術切面來單獨管理，以服務的形式給構建在雲上的應用提供簡單、易用、高效的分布式事務解決方案。

GTS 給業務應用帶來的價值體現在以下幾個方面：

• 架構復雜度降低：分布式事務這個 切面 的技術問題，全部 收斂 到 GTS 提供的服務來解決。
• 設計和開發成本減輕：業務邏輯的設計和開發，完全不需要針對是否涉及分布式事務而做任何額外的事情，對業務 0 侵入 。
• 項目交付、迭代速度加快：歸因於上述兩點，項目得以很快交付和迭代。GTS 賦予業務應用 快速試錯 的能力，在這個商業機會瞬息萬變的時代，顯得尤為重要。

設想一個典型的雲原生企業應用的成長路徑：

 

 

• 1.0：單體應用，快速上線，這個時候完全不涉及分布式事務。
• 2.0：單個數據庫無法支撐，數據分布到多個數據庫，產生分布式事務問題。
• 3.0：微服務化，進一步產生跨服務的分布式事務。
• 4.0：跨應用的整合，成為 SaaS 或 FaaS 的平台，在更大的范圍，產生分布式事務問題。

基於 GTS 提供的分布式事務服務，企業發展各階段產生的不同場景下的數據一致性問題，可以得到一站式的解決。這使得業務可以平滑自然地，像搭積木一樣成長起來。

從上面示例可以看到：GTS 實際上是把分布式事務（或者說分布式場景下的數據一致性）能力，作為一種 雲原生 的服務，提供給生長在雲上的應用，讓分布式事務不再成為業務要面臨的一個令人頭疼的問題，而成為一種可以彈性伸縮，按需取用的服務能力。

GTS 的原理和創新

下面，從幾個方面來大體介紹 GTS 的原理和創新。

首先，GTS 把分布式事務定義為由若干本地事務（分支）組成的全局事務。被全局事務管理的全部分支，將在協調器的協調下，保證一起成功或一起回滾。

 

 

其次，GTS 定義了一個事務模型，把整個全局事務過程模型化為 TM、RM、TC 三個組件之間協作的機制。

• Transaction Coordinator (TC)： 事務協調器，維護全局事務的運行狀態，負責協調並驅動全局事務的提交或回滾。
• Transaction Manager (TM)： 控制全局事務的邊界，負責開啟一個全局事務，並最終發起全局提交或全局回滾的決議。
• Resource Manager (RM)： 控制分支事務，負責分支注冊、狀態匯報，並接收事務協調器的指令，驅動分支（本地）事務的提交和回滾。

 

 

一個典型的分布式事務過程：

1. TM 向 TC 申請開啟一個全局事務，全局事務創建成功並生成一個全局唯一的 XID。
2. XID 在微服務調用鏈路的上下文中傳播。
3. RM 向 TC 注冊分支事務，將其納入 XID 對應全局事務的管轄。
4. TM 向 TC 發起針對 XID 的全局提交或回滾決議。
5. TC 調度 XID 下管轄的全部分支事務完成提交或回滾請求。

第三，GTS 創新地基於 SQL 解析實現對業務無侵入的自動補償回滾機制。這種機制，GTS 將其命名為 Auto Transaction (AT) 模式。基本工作原理如下：

GTS 把全局事務分為兩個階段：執行階段 和 完成階段 。

執行階段：

GTS 的 JDBC 數據源代理通過對業務 SQL 的解析，把業務數據在更新前后的數據鏡像組織成回滾日志，利用 本地事務 的 ACID 特性，將業務數據的更新和回滾日志的寫入在同一個 本地事務 中提交。

這樣，可以保證：任何提交的業務數據的更新一定有相應的回滾日志存在。

 

 

基於這樣的機制，分支的本地事務便可以在全局事務的 執行階段 提交，馬上釋放本地事務鎖定的資源。

完成階段：

• 如果 TM 發出的決議是全局提交，此時分支事務此時已經完成提交，不需要同步協調處理（只需要異步清理回滾日志），完成階段 可以非常快速地完成。

 

 

• 如果 TM 發出的決議是全局回滾，RM 收到協調器發來的回滾請求，通過 XID 和 Branch ID 找到相應的回滾日志記錄，通過回滾記錄生成反向的更新 SQL 並執行，以完成分支的回滾。

 

 

最后，GTS 通過事務協調器集群以及對業務應用節點的容錯，實現一個拒絕單點故障的高可用服務。

 

 

一方面，GTS 服務集群機制，保障任意服務節點宕機，可以其他節點無縫接管。 另一方面，應用任意節點的宕機，相應事務分支的請求也會路由到連接相同數據庫的其他節點上，不影響全局事務的完整執行。

分布式事務模式融合及標准化（保護）

截止目前，還沒有任何一種分布式事務的技術方案，可以滿足所有場景的問題。GTS 的 AT 模式適用於絕大部分常見場景，但仍有一些場景更適合於使用業界其他的分布式事務解決方案。GTS 會把各類解決方案融合到 GTS 提供的雲服務框架中，為雲原生應用提供一站式的分布式事務服務。

 

 

這是 GTS 的抽象出的事務框架。通過這個抽象，分布式事務得以從整體架構中剝離出來，形成一個單獨的技術切面，作為服務提供給應用。

簡單來說，基於這個框架的應用，其分布式事務問題，就收斂到基於 RM 的分支事務機制和 TC 提供的穩定、可靠的服務中。分而治之，才能更有效地解決問題。

當前分布式應用層面，最具代表性的事務模式有 4 種，分別是 AT、TCC、Saga 和 XA，這些模式各有優缺點和適用的場景。

下面列出 4 種事務模式的優劣，以及在 GTS 的事務框架中的映射。

AT

優勢： 業務無侵入；輕量，不依賴數據庫的高級特性；回滾較少的場景性能高。

劣勢： 隔離性不高，目前只能支持到接近 讀已提交 的程度，更高的隔離級別，實現成本將非常高。

 

TCC

優勢： 適用場景廣泛；隔離性和性能都可以做極致優化。

劣勢： 業務侵入性非常高。

 

 

Saga

優勢： 長事務。

劣勢： 有一定業務侵入性；隔離性差。

 

 

XA

優勢： 業務無侵入；隔離性好。

劣勢： 阻塞協議。

 

 

GTS 與開源

為了更好地構建一個雲原生的分布式事務標准，2019 年初，GTS 選擇了開源，發起了開源項目 SEATA（曾用名 FESCAR）。項目開源不到 1 年時間，收獲 STAR 數已經突破 1.2 萬，Contributor 超過 120 名，獲得社區的廣泛關注和認可。

分布式事務一直以來都可以稱得上是世界性難題，希望可以通過 SEATA 這個開放的平台，聚集全世界的智慧來給這道難題交上一份讓人滿意的答卷。

進一步，GTS 將這份答卷轉化為阿里雲上高效、穩定、可靠的服務，賦能給廣大雲原生開發者。

總結

GTS 自從 2014 年誕生於阿里巴巴中間件的 5 年來，從支撐集團內第一個業務方開始，經歷了從內部到雲產品化，從封閉到開源，從單一模式到兼容並蓄和標准化，一直堅定地走在分布式事務領域的最前沿。

GTS 的目標是雲原生時代，分布式事務的全面解決方案，任何分布式事務需求，在 GTS 上都能找到滿意的答案。

 

 

 

原文鏈接

本文為阿里雲內容，未經允許不得轉載。