问题标签 [2phase-commit]

想象一下，我们有 2 个执行汇款的节点。节点 A 发起从一个账户到另一个账户的转账，节点 B 负责完成这笔交易。因此，要完成此交易，节点 A 必须向节点 B 发送一些 TRANSFER 请求，并且在成功时节点 B 必须以确认 TRANSFER 请求来响应。我看到的可能问题如下：收到 TRANSFER 请求后，节点 B 执行了事务，但未能发送响应。所以节点A认为请求失败并报告问题，但事务实际上已经完成。

即使考虑两阶段提交协议（节点 B 在收到 TRANSFER 请求时不提交事务，而只是执行它并等待节点 A 的一些提交确认）也可能存在类似的问题：当节点 A 发送 TRANSFER 提交请求时无法确定节点 B 收到了该请求并且事务实际上已完成（即使该请求已传递到目标主机，我们也无法确定它是由某个进程提交的）。

如何解决这个问题或者它真的是一个问题？

我有两个微服务 A 和 B，它们连接到单独的数据库，从微服务 A 我需要在相同的转换中持久（保存）A 和 B 的对象如何实现这一点。

我正在使用带有 netflix-oss 的 Spring 微服务。请就完成 2 阶段提交的最佳方法提出建议。

谁能告诉我，为什么协调器失败时 2PC 会阻塞？是不是因为 2PC 中的队列没有使用超时概念？

很好的参考：两阶段提交和三阶段提交协议的分析和验证，作者 Muhammad Atif，

我试图推理保证同步数据源的系统/框架可以采取的故障恢复操作。我一直无法找到关于 Narayana 恢复机制的明确解释。

Q1：Narayana 是否本质上采用两阶段提交来确保跨 2 个数据源的分布式事务？

Q2：有人可以解释 Narayana 在这种情况下的行为吗？

1. 应用程序想要将 X 保存到 2 个数据存储
2. Narayana 的事务管理器 (TM) 生成事务 ID 并将信息写入磁盘
3. TM 现在向两个数据存储发送一条准备消息
4. 每个数据存储都以 prepare_success 响应
5. TM 更新本地事务日志并向两个数据存储发送提交消息
6. TM 失败（永久）。并且由于网络上的丢包，只有一个数据存储接收到提交消息。但其他数据存储接收并成功处理提交消息。

这两个数据存储现在彼此不同步（一个源具有另一个源中不存在的附加事务）。

启动新 TM 时，它无法访问旧的事务状态记录。因此，TM 无法在其中一个数据存储中启动丢失事务的恢复。

那么 2PC/Narayana/XA 如何声称他们保证分布式事务可以保持 2 个数据存储同步呢？从我的角度来看，他们只能以非常高的概率保持同步数据存储，但他们不能保证。

Q3：另一种情况，我不清楚应用程序/框架的行为。考虑以下交错事务（都在同一记录上 - 或至少具有部分重叠的记录集）：

• Di = 数据源 i
• Ti = 事务 i
• Pi = 为事务 i 准备消息

D1接收P1；响应 P1_success

D2接收P2；响应 P2_success

D1接收P2；响应 P2_failure

D2接收P1；响应 P1_failure

网络数据包到达不同数据源的顺序可以决定哪个准备请求成功。这是否意味着有争议的记录在高交易速度下 - 所有交易都可能会继续失败（直到记录经历较低的交易请求率）？

有人可能会争辩说，我们选择的是一致性而不是可用性，但与 ACID 系统不同，不能保证至少有一个事务会成功（从而避免潜在的长期死锁）。

DRBD 采用什么协议来保证它可以保持 2 个磁盘彼此同步？

它是否使用两阶段提交（或类似于 2PC 的变体）？

DRBD 是否有一个异步/离线协调器不断检查磁盘是否有偏差？

考虑这种情况。

1. Coordinator 向 2 个参与者发送准备消息，然后崩溃
2. 参与者锁定资源成功，然后等待协调者恢复
3. Coordinator 恢复，但没有收到参与者关于 prepare_success 消息的消息

是否需要人工干预才能解锁锁定的资源？或者参与者是否轮询协调器以查找事务的状态？

一开始，这听起来类似于参与者没有收到提交消息的情况，但主要区别在于协调者在该场景中重新驱动消息。在上面列出的场景中，协调器甚至不知道它必须重新驱动一个全局事务，因为它的日志中没有记录它。

如何在非事务性、轻量级的环境中保证消息传递？

例如：

• 正常情况：写入数据库，提交，向 ZeroMQ|Redis|OtherMQ 发送消息，消费者拉取消息继续处理...
• 0,05% 情况：写入数据库，提交，应用程序死掉！，没有消息发送，没有消费者拉消息，处理不完整。

在这种情况下如何不丢失消息（避免不发送消息）？

编辑：消息必须只发送一次。

我有一种情况，作为在线交易的一部分，我必须将一些数据保存到其他数据库中，更新其他数据库时有一点延迟（几秒钟）就可以了。现在由于两个数据库都是 Oracle，我有以下 3 个选项，我需要了解哪个更好。

1. Oracle 数据库链接：其中我将 SQL 转换为 PL/SQL，并让我的数据库负责写入另一个基于 Oracle 的 DEV 环境数据库，这两个数据库都在同一服务器中作为不同的模式，而在生产中它们恰好是两个独立的 ORACLE RAC由几个路由器和交换机隔开。

2. Spring Batch：以某种方式使用批处理作业从我的源数据库中选择事务并处理并写入另一个目标数据库。这样我的在线交易就不会失败，因为其他数据库出现故障或遇到性能问题或面临网络问题。如果他们失败了，我可以为工作重新启动能力编写代码。Spring batch 是否适合这种事件发布案例？我将来会遇到任何挑战吗？

3. 2-Phase-Commit：我简单地实现了 2PC 并将数据保存在两个数据库中的事务中。或者也许让它看起来更面向未来并保存在消息传递系统和我的源数据库中。

正在执行分布式更新，我收到此 ORA-24756 错误：

此错误来自失败的两阶段提交，我还发现 SYS.PENDING_TRANS$/SYS.PENDING_SESSION$/dba_2pc_pending 中有一些记录 (trans_id = "6.42.332492") 处于“准备”状态。此事务是通过 JDBC 从 Weblogic Server 启动的。\ 如何解决此 ORA-24756 错误？

我是分布式事务的新手，正在研究两阶段提交如何在微服务架构中的分布式事务中工作。据我了解，在该阶段的最后一部分，事务协调器会询问每个节点是否准备好提交。如果每个人都同意，那么它会告诉他们继续并承诺。

但是是什么阻止了以下失败？

所有节点都响应他们已准备好提交事务协调器告诉他们“继续并提交”但其中一个节点在提交时失败（例如由于某些数据库约束或连接超时）

所有其他节点都成功提交，但现在分布式事务已损坏

简而言之，当节点说它们准备好提交时，这意味着什么？

我假设每个节点都在运行一个对分布式事务一无所知的普通数据库。