2PC跨多个微服务的分布式事务？

Question

我阅读了一些关于2阶段提交/ XA分布式事务的信息，以及JTA如何支持它。似乎有许多资源经理- RM (例如。RDBMS或JMS)，以及一个管理多个RM的全局事务的TransactionManager (TM)实例。

​

我知道使用Saga模式更好，但仍然很有趣：

1. Do 2 2PC/XA分布式事务使有可能只从一个应用程序和一个TM执行多个RM的事务
2. 如果没有-如何使用2 2PC /XA分布式事务在多个微服务之间提供使用2pc的能力，如果每个微服务只能访问自己的数据库？我很高兴看到一个例子
3. 我们是否需要使用TransactionManager服务作为一个单独的微服务，以便在多个微服务之间提供2PC？

UPD: JTA TransactionManager 没有提供REST 来管理跨微服务的事务。LIXA提供了这个能力。文章附例，除了答案:)

Answer 1

跨微服务，事务需要通过公开准备和提交API来完成。此外，需要有一个事务管理器来协调事务。

例如，假设有两个不同的银行，而来自Account_A of Bank1的100美元必须转移到Account_B of Bank2。此外，假设中央银行管理局负责完成交易，2PC的工作方式如下：

1. 中央银行管理局(交易经理)将收到从Account_A将100美元从Bank1转到Bank2的Account_B的请求。 a. B&amount=100
2. 中央银行将使用一些交易Id = 123将其事务数据库保存起来。此外，它还将返回事务id来调用，以便在以后调用获得事务状态。 a.在数据库中添加状态打开的事务123
3. 准备阶段事务管理器将发出以下RPC命令： a. A&money=100&action=subtract&transactionid=123 b. B&money=100&action=add&transactionid=123
4. 提交阶段一旦在准备阶段成功地响应了这两个调用，然后移动到提交阶段，在这里它发出以下命令： a.将事务123移至提交的b. https://Bank1/Commit?transactionid=123 c. https://Bank2/Commit?transactionid=123状态
5. 一旦在提交阶段成功响应了这两个调用，中央银行就可以将事务转移到已完成的状态(可选)。
6. 如果准备阶段或提交阶段的任何步骤失败，事务协调器将通过发出以下命令中止事务： 将事务123移动到失败的b. https://Bank1/Rollback?transactionid=123 c. https://Bank2/Rollback?transactionid=123状态。

上面的问题是分布式原子提交的形式，而2PC是实现它的一种方法。还注意到2PC有很多不利因素，比如在准备阶段之后，央行崩溃了怎么办。如果4.c步骤失败，但4.b成功等，讨论这些本身是非常广泛的研究，但仍然是一些值得注意的事情。尽管有很多缺点，但由于其简单性，2PC被广泛使用。

我们是否需要使用TransactionManager服务作为一个单独的微服务，以便在多个微服务之间提供2PC？

理论上没有。如果您仔细观察到任何一个银行(Bank1或Bank2)也可以充当事务管理器(它只需要一个单独的数据库表事务)，但实际上很多时间都是作为单独的微服务来保存的。