问题标签 [2phase-commit]

我已经阅读了许多文章并感到困惑。

意见 1：2PC 非常高效，交换的消息数量最少，延迟低。资料来源： http ://highscalability.com/paper-consensus-protocols-two-phase-commit

意见 2：分布式事务很难扩展到高水平，而且它们会降低吞吐量。作为 2PC 保证 ACID 由于其复杂的协调算法，它带来了很大的负担。资料来源：http: //ivoroshilin.com/2014/03/18/distributed-transactions-and-scalability-issues-in-large-scale-distributed-systems/

意见 3：“一些作者声称两阶段提交太昂贵而无法支持，因为它带来了性能或可用性问题。我们认为最好让应用程序程序员在出现瓶颈时处理由于过度使用事务而导致的性能问题，而不是总是围绕缺乏事务进行编码。在 Paxos 上运行两阶段提交可以缓解可用性问题。” 资料来源：http ://courses.cs.washington.edu/courses/csep552/13sp/lectures/6/spanner.pdf

意见 4：2PC 协调器也代表单点故障，这对于关键系统来说是不可接受的——我相信它是一个协调器。资料来源： http: //www.addsimplicity.com/adding_simplicity_an_engi/2006/12/2pc_or_not_2pc_.html

前 3 种观点相互矛盾。我认为第4个是正确的。请澄清什么是错误的，什么是正确的。给出事实为什么会这样也很好。

我有一个关于在 zookeeper 集群中实现两阶段提交协议以协调多个客户端连接之间的某些事务的问题。现在我有以下想法：

• 协调C器注册交易节点/app/tx
• 为每个相关方注册处理节点/app/tx/%d (Ni)
• 在每个相关方节点上设置观察者Ni
• 通知每个Ni人新的交易tx
• Ni检查其节点是否已创建
• Ni将事务设置为 prepare()/abort()
• C从各方接收结果并决定中止/继续
• 如果继续，每个Ni执行查询
• NC我用 ok/fail通知
• C决定中止|提交
• C通知大家结果。
• tx已承诺

但我不确定这是一个正确的方向吗？而且我不确定如何在 python kazoo 或任何其他语言（Java）中实现这一点？如果您可以通过提供片段或纠正我的算法来帮助我，那会很好吗？另外，如何扩展这个协议以实现 Zookeeper 间的通信？比如说，我们维护多个不同的 Zookeeper 集群，这些集群被包装到区域或任何其他抽象实体中，我们希望使用两阶段提交在特定区域上执行此类显式事务？

我对这两种技术感到很困惑。

1. 这两种技术之间有什么关系吗

2. 是否有任何现有的流行开源软件实现了这些技术？我知道 zookeeper 实现了 Paxos，但是两阶段提交呢？

今天我被甲骨文没有实现的成功的 2pc 击中。另一个参与者是 MSMQ，它实现得很好。

问题是我没有在应用程序中得到异常（使用 c# odp.net）。后来我在 sys.dba_2pc_pending 中找到了 In-Doubt Transactions。

我能以某种方式在我的应用程序中检测到这一点吗？

编辑：这不是让 2pc 工作。它确实有效，并且持续了一年多，直到有一天某些行丢失。请阅读 In-Doubt Oracle 事务链接1和待处理事务链接 2

为了在分布式事务中充当 RM（资源管理器），DBMS 必须实现两阶段提交。就像在 PostgreSQL 中一样，当您第一次“预提交”本地事务时：

然后提交：

我的问题是：MS SQLServer 是否支持这样的功能？

我有一个 EJB 计时器 (EJB 2.1)，它具有 bean 托管事务。

计时器代码调用一个业务方法，该方法在单个事务中处理 2 个资源。一种是数据库，另一种是 MQ 队列服务器。

使用的应用服务器是 Websphere Application Server 7 (WAS)。为了确保跨 2 个资源（数据库和队列管理器）的一致性，我们在 WAS 中启用了支持 2 阶段提交的选项。这是为了确保在数据库操作过程中发生任何异常时，发布在队列中的消息会随着数据库回滚而回滚，反之亦然。

以下是解释的流程：

当 Timer 代码发生超时时，调用 DirectProcessor 中的 startProcess()，这是我们的业务方法。此方法有一个 try 块，其中有一个对同一类中的 createPostXMLMessage() 的方法调用。这又调用了 PostMsg 类中的另一个方法 postMessage()。

问题是当我们在 createPostXMLMessage() 方法中遇到任何数据库异常时，虽然数据库部分成功回滚，但之前发布的消息不会回滚。请帮忙。

在 ejb-jar.xml

最近我多次读到两阶段提交是不好的，但总是作为旁注。所以从来没有一个很好的解释。

例如在CQRS Journey 第 5 章中：

其次，我们试图避免两阶段提交，因为从长远来看它们总是会导致问题。

或者在第 563 页的实现领域驱动设计中：

基础设施使用第二个 ReadRecorts() 来复制事件，在不需要两阶段提交的情况下发布它们，...

我认为实现了两阶段提交以确保多个数据库服务器之间的一致性。

使用两阶段提交时会出现什么问题？为什么最好避免它们？

我指的是https://en.wikipedia.org/wiki/Two-phase_commit_protocol上对两阶段提交的描述。

在预提交阶段，假设两个资源经理都投了赞成票。

如果事务管理器通过向每个资源管理器发送 COMMIT 消息来发起提交，并且其中只有一个返回 ACK，而另一个没有，事务管理器如何从第一个成功提交的资源管理器回滚已经提交的事务?

当全局事务失败时，是否有可能在一个资源管理器上而不是另一个资源管理器上提交事务？

我试图让 WebAPI 2.2 自托管在 Linux 环境中，这可以用 Mono 来完成，问题是我正在使用分布式事务的事务范围，那么非 Windows 平台是否支持它（DTC）？如果没有，是否有任何解决方法或替代方法可以在没有 DTC 的情况下实施 2pc？

在 ZooKeeper Programmer's Guide 的Consistency Guarantees部分中，它指出 ZooKeeper 将提供“单一系统映像”保证：

无论客户端连接到哪个服务器，客户端都将看到相同的服务视图。

根据 ZAB 协议，只有超过一半的追随者确认提案，领导者才能提交交易。所以很可能不是所有的追随者都处于相同的状态。

如果follower的状态不同，ZooKeeper怎么保证“单系统状态”呢？

参考：

• ZooKeeper 的原子广播协议：理论与实践
• 单一系统映像