3大主流分散式事務框架詳解（圖文總結）

Hello-Brand發表於2024-07-10
分散式框架

1 簡要介紹

隨著微服務架構的不斷髮展，分散式系統逐漸普及到後端領域的每一個角落。
在分散式系統中，跨多個服務的資料一致性一直是一個重大挑戰，為解決這一挑戰，分散式事務應運而生。
作者在之前的文章《五種分散式事務解決方案》和《4大主流分散式演算法介紹》中，詳細介紹了分散式事物的解決方案以及實現原理。接下來，咱們詳細介紹下行業內主流的幾個分散式事務框架，以及他們的實現原理。

2 主流分散式事務框架

2.1 Seata

Seata是一款由阿里巴巴開源的分散式事務解決方案，致力於在微服務架構下提供高效能和簡單易用的分散式事務服務。它解決了分散式系統中的資料一致性問題，幫助開發者在分散式場景下實現ACID事務的支援。

2.1.1 核心元件

Seata 包含三個核心元件：

  1. Transaction Coordinator (TC)：事務協調者，維護全域性和分支事務的狀態，驅動全域性事務提交或回滾。
  2. Transaction Manager (TM)：事務管理器，定義全域性事務的範圍：開始全域性事務、提交或回滾全域性事務。
  3. Resource Manager (RM)：資源管理器，管理分支事務處理的資源，與TC交談以註冊分支事務和報告分支事務的狀態，並驅動分支事務提交或回滾。

以上三個元件相互協作，TC 以 Seata 伺服器（Server）形式獨立部署，來協調各個微服務分支的事務狀態，保證全域性的事務執行。TM 和 RM 則是以 Seata Client 的形式整合在微服務中執行。
下面用一張圖來說明：

image

工作流程如下：

  • TM 向 TC 申請建立一個全域性事務，建立成功後，同步生成一個全域性唯一的 XID。此時全域性事務已開啟。
  • XID 透過服務的呼叫鏈傳遞到其他服務
  • RM 向 TC 註冊一個分支事務，並將其納入 XID 對應全域性事務的管轄
  • TM 根據 TC 收集的各個分支事務的執行結果，向 TC 發起全域性事務提交或回滾決議
  • TC 排程 XID 下管轄的所有分支事務，如果都成功則完成提交，否則回滾操作

2.1.2 工作模式

Seata 支援三種工作模式：

  1. AT模式（基於支援本地ACID事務的資料庫）：

    • 無需侵入業務程式碼，基於資料層
    • 兩階段提交協議的變種
    • 效能較好，但存在髒回滾的風險（回滾日誌的生成和清理）

  2. TCC模式（Try-Confirm-Cancel）：

    • 侵入業務程式碼
    • 開發者需要編寫Try、Confirm、Cancel介面
    • 無鎖，高效能

  3. Saga模式：

    • 長事務解決方案
    • 透過事件驅動的方式，允許業務自定義正向和補償操作
    • 適用於業務流程長、業務流程多、參與方多的場景

2.1.3 核心特性

  1. 高效能：Seata 採用了高效的通訊協議和事務處理機制，確保在高併發場景下依然能夠保持高效能。
  2. 簡單易用：Seata 提供了簡單易用的API和配置，開發者可以快速整合和使用。
  3. 擴充套件性：Seata 支援靈活的擴充套件機制，可以根據業務需求定製各種擴充套件元件。
  4. 社群支援：作為阿里巴巴開源專案，Seata 得到了廣泛的社群支援和貢獻。

2.2 ByteTCC

ByteTCC 是一個基於 TCC（Try/Confirm/Cancel）機制的分散式事務管理器。它旨在解決微服務架構下分散式事務的一致性問題，透過將事務拆分為多個階段（Try、Confirm、Cancel）來確保事務的原子性。ByteTCC 相容 JTA 規範，可以很好地與 EJB、Spring 等容器進行整合。值得注意的是，相對於通用事務工框架Seata，ByteTCC更專注於TCC模式，與Java生態結合的非常好。

2.2.1 工作原理

ByteTCC 的工作原理基於 TCC 模式，將事務分為三個階段：

  1. Try 階段：在此階段，事務參與者嘗試執行事務的一部分，並記錄相應的狀態和資料。如果所有參與者的 Try 階段都成功，則進入 Confirm 階段；否則，進入 Cancel 階段。
  2. Confirm 階段：在此階段，如果 Try 階段成功，則參與者將確認事務的執行，並進行最終的提交。如果 Confirm 階段成功，則全域性事務提交；否則，根據失敗情況決定是回滾還是進行補償操作。
  3. Cancel 階段：如果 Try 階段失敗或 Confirm 階段出現問題，則進入 Cancel 階段。在此階段，參與者將進行事務的回滾，以確保資料的一致性。

image

2.2.2 核心特性

  1. 支援多種事務機制：ByteTCC 支援普通事務、TCC 事務、Saga 事務等事務機制，以適應不同的業務需求。
  2. 跨應用、跨伺服器支援：ByteTCC 支援多資料來源、跨應用、跨伺服器等分散式事務場景，確保資料在分散式環境下的一致性。
  3. 長事務處理：ByteTCC 適用於處理耗時較長但仍需保持事務性的操作。
  4. 支援多種服務框架：ByteTCC 支援 Dubbo 和 Spring Cloud 等主流服務框架，使得開發者能夠在不同框架下輕鬆啟用分散式事務。
  5. 宣告式事務管理：透過簡單的註解，開發者可以將普通服務轉換為 TCC 服務，降低開發難度。

2.2.3 存在的缺點

  • 服務侵入性強，每個事務都必須實現 Try、Confirm、Cancel 三個方法，成本高
  • 為了保證事務一致性，Try、Confirm、Cancel 介面必須實現冪等
  • 記錄事務日誌，必定會損耗一定的效能，並使得整個 TCC 事務時間拉長

2.2.4 應用場景

ByteTCC 可廣泛應用於金融、電商等領域，尤其適用於涉及多個服務互動的複雜交易場景，例如資金轉賬、訂單建立等。透過其強大功能，可以確保在分散式環境中實現事務的一致性和可靠性，有效防止資料不一致的問題。

2.3 TCC-Transaction

TCC-Transaction：華為開源的分散式事務框架，基於TCC補償機制實現，支援高效能和高可用，提供了簡單易用的API介面和工具支援。
可以擴充套件閱讀下這篇文章《TCC-Transaction分散式事務》，寫的比較清楚，我這邊就不贅述了。

3 總結

無論哪種事務框架，目標無非是實現分散式系統的資料一致性。當然代價也是有的，比如
服務侵入，成本提升、效能開銷等，都需要衡量。使用前可以先期調研，選擇最適合的框架。

相關文章