2019 年 3 月，螞蟻金服加入分布式事務 Seata 的社區共建中，并貢獻其 TCC 模式。本期是 SOFAChannel 第四期，主題：分布式事務 Seata TCC 模式深度解析，本文根據覺生的直播整理。
大家晚上好，我是 Seata Committer 覺生，來自螞蟻金服數據中間件團隊。今天的內容主要分為以下四個部分：
Seata TCC 模式的原理解析；
從 TCC 的業務模型與并發控制分享如何設計一個 TCC 接口，并且適配 TCC 模型；
如何控制異常；
性能優化，使得 TCC 模式能夠滿足更高的業務需求。

1 Seata 的 TCC 模式

1.1 服務化拆

下面我們就進入第一個主題，Seata 的 TCC 模式。螞蟻金服早期是單系統架構，所有業務服務幾乎都在少數幾個系統中。隨著業務的發展，業務越來越復雜，服務之間的耦合度也越來越高，故我們對系統進行了重構，服務按照功能進行解耦和垂直拆分。拆分之后所帶來的問題就是一個業務活動原來只需要調用一個服務就能完成，現在需要調用多個服務才能完成，而網絡、機器等不可靠，數據一致性的問題很容易出現，與可擴展性、高可用容災等要求并肩成為金融 IT 架構支撐業務轉型升級的最大挑戰之一。

從圖中可以看到，從單系統到微服務轉變，其實是一個資源橫向擴展的過程，資源的橫向擴展是指當單臺機器達到資源性能瓶頸，無法滿足業務增長需求時，就需要橫向擴展資源，形成集群。通過橫向擴展資源，提升非熱點數據的并發性能，這對于大體量的互聯網產品來說，是至關重要的。服務的拆分，也可以認為是資源的橫向擴展，只不過方向不同而已。

資源橫向擴展可能沿著兩個方向發展，包括業務拆分和數據分片：

業務拆分。根據功能對數據進行分組，并將不同的微服務分布在多個不同的數據庫上，這實際上就是 SOA 架構下的服務化。業務拆分就是把業務邏輯從一個單系統拆分到多個微服務中。

數據分片。在微服務內部將數據拆分到多個數據庫上，為橫向擴展增加一個新的維度。數據分片就是把一個微服務下的單個 DB 拆分成多個 DB，具備一個 Sharding 的功能。通過這樣的拆解，相當于一種資源的橫向擴展，從而使得整個架構可以承載更高的吞吐。

橫向擴展的兩種方法可以同時進行運用：交易、支付與賬務三個不同微服務可以存儲在不同的數據庫中。另外，每個微服務內根據其業務量可以再拆分到多個數據庫中，各微服務可以相互獨立地進行擴展。

Seata 關注的就是微服務架構下的數據一致性問題，是一整套的分布式事務解決方案。Seata 框架包含兩種模式，一種是 AT 模式。AT 模式主要從數據分片的角度，關注多 DB 訪問的數據一致性，當然也包括多服務下的多 DB 數據訪問一致性問題。
另外一個就是 TCC 模式，TCC 模式主要關注業務拆分，在按照業務橫向擴展資源時，解決微服務間調用的一致性問題，保證讀資源訪問的事務屬性。

今天我們主要講的就是 TCC 模式。在講 TCC 之前1.2 AT 模式

對于 AT 模式，之前其他同學已經分享過很多次，大家也應該比較熟悉了。AT 模式下，把每個數據庫被當做是一個 Resource，Seata 里稱為 DataSource Resource。業務通過 JDBC 標準接口訪問數據庫資源時，Seata 框架會對所有請求進行攔截，做一些操作。每個本地事務提交時，Seata RM（Resource Manager，資源管理器） 都會向 TC（Transaction Coordinator，事務協調器） 注冊一個分支事務。當請求鏈路調用完成后，發起方通知 TC 提交或回滾分布式事務，進入二階段調用流程。此時，TC 會根據之前注冊的分支事務回調到對應參與者去執行對應資源的第二階段。TC 是怎么找到分支事務與資源的對應關系呢？每個資源都有一個全局唯一的資源 ID，并且在初始化時用該 ID 向 TC 注冊資源。在運行時，每個分支事務的注冊都會帶上其資源 ID。這樣 TC 就能在二階段調用時正確找到對應的資源。

這就是我們的 AT 模式。簡單總結一下，就是把每個數據庫當做一個 Resource，在本地事務提交時會去注冊一個分支事務。

1.3 TCC 模式

那么對應到 TCC 模式里，也是一樣的，Seata 框架把每組 TCC 接口當做一個 Resource，稱為 TCC Resource。這套 TCC 接口可以是 RPC，也以是服務內 JVM 調用。在業務啟動時，Seata 框架會自動掃描識別到 TCC 接口的調用方和發布方。如果是 RPC 的話，就是 sofa:reference、sofa:service、dubbo:reference、dubbo:service 等。

掃描到 TCC 接口的調用方和發布方之后。如果是發布方，會在業務啟動時向 TC 注冊 TCC Resource，與 DataSource Resource 一樣，每個資源也會帶有一個資源 ID。

如果是調用方，Seata 框架會給調用方加上切面，與 AT 模式一樣，在運行時，該切面會攔截所有對 TCC 接口的調用。每調用一次 Try 接口，切面會先向 TC 注冊一個分支事務，然后才去執行原來的 RPC 調用。當請求鏈路調用完成后，TC 通過分支事務的資源 ID 回調到正確的參與者去執行對應 TCC 資源的 Confirm 或 Cancel 方法。

在講完了整個框架模型以后，大家可能會問 TCC 三個接口怎么實現。因為框架本身很簡單，主要是掃描 TCC 接口，注冊資源，攔截接口調用，注冊分支事務，最后回調二階段接口。最核心的實際上是 TCC 接口的實現邏輯。下面我將根據螞蟻金服內部多年的實踐來為大家分析怎么實現一個完備的 TCC 接口。，我們先回顧一下 AT 模式，這樣有助于我們理解后面的 TCC 模式。

2 TCC 業務模式與并發控制

2.1 TCC 設計原則

總結

以上是生活随笔為你收集整理的阿里巴巴开源分布式框架Seata TCC模式深入分析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。