标签: 2phase-commit

我正在寻找两阶段提交协议的实现，是的，我是分布式事务的新手:) 必须在 php 应用程序和远程“应用程序”（系统）之间实现两阶段提交。

我是否必须从头开始实施两阶段提交？您是否知道以任何语言实现的任何模块可以让我领先一步？

- 直到现在找不到太多关于此的信息:)

感谢任何帮助。

我阅读了一些关于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 提供了这种能力。除答案外还附有示例的文章:)

所有事务管理器(Atomikos,Bitronix,IBM WebSphere TM等)都将一些"事务日志"保存到文件系统的"tranlogs"文件夹中.

当一些可怕的事情发生并且服务器崩溃时,有时变更会被破坏.它们需要一些手动恢复程序.

我被告知,通过简单地清除已损坏的tranlogs文件夹,我冒着参与交易的资源状态不一致的风险.

作为一个"愚蠢"的开发者,我对简单的概念感到更舒服.我想认为分布式事务管理应该与常规事务管理相似:

1. 如果在任何一方出现问题(网络,应用程序错误,超时) - 我希望整个多资源事务不会在其任何部分提交.应尽快清理所有剩菜.
2. 如果事务管理器出现故障(文件系统故障,电源故障) - 我预计此TM下的所有事务都将被回滚(显然,在数据库超时级别).
3. 如果我不想进行任何自动TX恢复(无论它意味着什么),则tranlogs的文件存储是可选的.

问题

为什么我不这样想？2PC有什么这么复杂的？

当我清除损坏的tranlogs时,确切的风险是什么？

如果我错了,我真的需要所有混乱的2PC文件系统状态.TX经理是否能够以简单而丑陋的方式实际破坏存储状态这一事实,您是否感到恶心？

我有两个mico-serives A和B,它们连接到单独的数据库,从Mico-serives A我需要在同一个转换中持久保存(保存)A和B的对象如何实现这一点.

我正在使用带有netflix-oss的Spring微服务.请给出关于执行2阶段提交的最佳方法的建议.

当我们需要更改两个系统中的数据时，双写入就会出现问题：数据库（SQL 或 NoSQL）和 Apache Kafka（例如）。必须可靠地/自动地更新数据库并发布消息。最终一致性是可以接受的，但不一致是不能接受的。

如果没有两阶段提交 (2PC)，双写入会导致不一致。

但在大多数情况下，2PC 并不是一个选择。

事务发件箱是一种微服务架构模式，其中单独的消息中继进程将插入数据库的事件发布到消息代理。

并行运行的多个消息中继进程会导致发布重复项（2 个进程读取 OUTBOX 表中的相同记录）或无序（如果每个进程只读取 OUTBOX 表的一部分）。

单个消息中继进程也可能多次发布消息。消息中继可能会在处理 OUTBOX 记录之后但在记录它已完成此操作的事实之前崩溃。当消息中继重新启动时，它将再次发布相同的消息。

如何在事务发件箱模式中实现消息中继，以便将重复消息或无序的风险降至最低，并且该概念适用于所有 SQL 和 NoSQL 数据库？

我正在编写一个不支持两阶段提交的资源适配器.我知道有一种称为"最后资源优化"的优化技术.

在JBoss上,您的XAResource类应该实现LastResource以进行优化.

我的问题是:如何在WebLogic,WebSpehre,Glassfish等中完成这项工作......

是否有一个开源Java库,它为本机不支持它的数据库添加了XA支持？也就是说,它包装了一个非XA JDBC数据源,并负责两阶段提交的幕后必要的提交/回滚？