共計 2925 個字符，預計需要花費 8 分鐘才能閱讀完成。

這篇文章主要講解了“分布式事務 GTS 的價值和原理是什么”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著丸趣 TV 小編的思路慢慢深入，一起來研究和學習“分布式事務 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)：控制分支事務，負責分支注冊、狀態匯報，并接收事務協調器的指令，驅動分支（本地）事務的提交和回滾。

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

TM 向 TC 申請開啟一個全局事務，全局事務創建成功并生成一個全局唯一的 XID。

XID 在微服務調用鏈路的上下文中傳播。

RM 向 TC 注冊分支事務，將其納入 XID 對應全局事務的管轄。

TM 向 TC 發起針對 XID 的全局提交或回滾決議。

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 的價值和原理是什么”的內容了，經過本文的學習后，相信大家對分布式事務 GTS 的價值和原理是什么這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是丸趣 TV，丸趣 TV 小編將為大家推送更多相關知識點的文章，歡迎關注！