跨多個微服務的 2PC 分布式事務？

Question

我閱讀了一些關於2 Phase Commit/XA 分布式事務以及 JTA 如何支持它的信息。 似乎有許多資源管理器 - RM（例如 RDBMS 或 JMS），以及一個跨多個 RM 管理全局事務的TransactionManager (TM)實例。

我知道最好使用Saga 模式，但想想還是很有趣：

1. 2PC/XA 分布式事務是否可以僅通過一個應用程序和一個 TM 與多個 RM 進行事務？
2. 如果沒有 - 如果每個微服務只能訪問自己的數據庫，如何在許多微服務之間使用 2PC/XA 分布式事務來提供使用 2PC 的能力？ 我很高興看到一個例子
3. 我們是否需要將TransactionManager服務作為一個單獨的微服務來提供多個微服務之間的 2PC？

UPD：在 JTA 世界中， TransactionManager不提供 REST API來管理跨微服務的事務。 LIXA 提供了這種能力。 除了答案之外還有示例的文章:)

Answer 1

在微服務中，事務需要通過公開 Prepare & Commit API 來完成。 還需要有一個事務管理器來協調事務。

例如，假設有 2 個不同的銀行，並且必須將來自 Bank1 的 Account_A 的 100 美元轉移到 Bank2 的 Account_B。 此外，假設中央銀行機構負責交易以完成 2PC 的工作方式，如下所示：

1. 中央銀行機構（交易經理）將收到將 100 美元從 Bank1 的 Account_A 轉移到 Bank2 的 Account_B 的請求。

    a. https://CentralBank/Transaction?from=Bank1-Account_A&to=Bank2-Account_B&amount=100

2. 中央銀行會將其保存到其交易數據庫中，其中一些交易 ID = 123。它還將返回交易 ID 以供調用，以便稍后它可以調用以獲取交易狀態。

    a. add transaction 123 in database with status open

3. PREPARE PHASE事務管理器將發出以下 RPC 命令：

    a. https://Bank1/Prepare?Account=Account_A&money=100&action=subtract&transactionid=123 b. https://Bank2/Prepare?Account=Account_B&money=100&action=add&transactionid=123

4. 提交階段一旦它在准備階段的兩個調用都獲得成功響應，然后它會移動到提交階段，它會發出以下命令：

    a. move transaction 123 to committed state b. https://Bank1/Commit?transactionid=123 c. https://Bank2/Commit?transactionid=123

5. 一旦在提交階段的兩個調用都獲得成功響應，中央銀行可以將交易轉移到已完成狀態（可選）

6. 如果 PREPARE 或 COMMIT 階段的任何步驟失敗，則事務協調器通過發出以下命令中止事務：

    a. move transaction 123 to Failed state b. https://Bank1/Rollback?transactionid=123 c. https://Bank2/Rollback?transactionid=123

---

上面的問題是分布式原子提交的形式，而 2PC 是一種方法。 另請注意，2PC 有很多缺點，例如在准備階段中央銀行崩潰之后會怎樣。 此外，如果 4.c 步驟失敗但 4.b 成功等等怎么辦。討論這些本身就是非常廣泛的研究，但仍然需要注意。 盡管 2PC 有很多缺點，但由於其簡單性而被廣泛使用。

---

我們是否需要將 TransactionManager 服務作為一個單獨的微服務來提供多個微服務之間的 2PC？

理論上不會。如果您仔細觀察任何銀行（Bank1 或 Bank2）也可以充當事務管理器（它只需要一個單獨的數據庫表 Transaction），但實際上很多時候它被保存為單獨的微服務。