问题标签 [2phase-commit]

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

没有 2 阶段提交 (2PC) 双重写入会导致不一致。

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

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

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

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

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

我有 2 个数据库。一个是 SQL Server，另一个是 MongoDB。这两个数据库都托管在 AWS 上。

我需要创建一个定期运行（可能每月一次）的 .NET 后台服务，并更新 SQL Server 和 MongoDB 中的大量数据。而且我需要在单个“分布式事务”中执行此操作，以便 2 个 DB 之间没有数据不一致并且数据是同步的。
我已经阅读过，2 Phase transactions但我认为这里不可能，因为 MongoDB 不支持事务？（如果我错了，请纠正我，但我们使用的是 MongoDB 3.4，我认为这不支持事务）。
所以我打算看看我是否可以实现saga pattern分布式事务？
我应该研究其他任何模式/技术来完成这项工作吗？

Imagen 您在从 PHP 调用的数据库中有一个存储过程。该过程像事务一样工作，并将数据选择/插入到数据库中。如果成功则提交，如果失败则回滚。

现在想象一下，您需要通过 REST 在外部系统中存储相同的数据 - 在事务中。

因此，如果您首先运行存储过程并且它提交，那么如果 API 调用失败，您将无法回滚数据库。如果您首先运行 API 调用并且它成功了，那么如果存储过程失败，您将无法回滚 API 调用。

我需要在 PHP 的一个事务中更新本地数据库 (SP) 和两个不同的 API 端点。

任何人都可以就如何管理这笔交易提供建议吗？

谢谢！

场景：我有多个符合 XA 的数据库，这些数据库前面有不同的微服务，它们对它们执行 CRUD 操作。我需要在这些微服务中执行 2 阶段提交。这意味着我有一个正在运行的服务器，它对这些微服务进行 API 调用以进行一些更新，这些更新应该是事务性的。我们计划创建一个事务管理器来管理它。

问题：所有可用的解决方案（如 Atomikos 等）都要求不同的事务发生在同一台服务器上，但在我的情况下，这些事务发生在不同的微服务中。在这种情况下，我们如何提供事务管理？最终，我们想要准备事务，然后在由我们自己的事务管理器管理的不同会话中提交它们。那可能吗？

我看过几篇关于 XA/分布式事务协调器的文章，其中许多只是提到 DBMS 必须明确支持 XA 才能运行。他们还讨论了分布式事务协调器的工作原理。但是，在阅读了很多这些信息之后，是的，我知道 DTC 是做什么的，但我什至不知道如何开始。

看了这么久，但我没有找到开箱即用的 DTC。我们需要自己实现DTC吗？没有任何现有的可用 DTC 框架吗？

一些相关的 StackOverflow 帖子：

两阶段提交如何防止最后一秒的失败？

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

如何在 postgresql 中处理分布式事务？

在 .NET 中，我们可以灵活地使用任务并行概念同时调用多个服务。考虑到我有三个不同任务的场景，每个任务调用不同的服务。

例如，

• 任务 1 服务 - 在应用程序数据库中发布数据
• 任务 2 服务 - 在集中式数据库中发布数据
• 迁移数据库中的任务 3 服务发布数据。

因此，假设这三个服务并行执行，并且任务 1 已完成，但任务 2 服务由于某些异常而失败。因此，由于这个原因，我要处理这样的事情，任务 1 应该回滚更改。我需要一个适当的解决方案，请告诉我。

两阶段提交可以解决这个问题。

在 2 阶段提交中，假设其中一个节点在提交阶段崩溃或速度很慢，而其他节点已经成功提交了他们的更改。现在，如果向其中一个成功的节点发出查询，从客户端的角度来看，它的数据一致性是什么？

客户端是否看到该成功节点上最新提交的更改，或者事务协调器是否将先前成功的 TransactionID 与查询一起传递给节点，以便客户端只能看到当前正在进行的事务之前的数据/状态？

我在网上遇到了以下结果：
1）2PL 确保冲突可序列化（cs），从而避免不可序列化的时间表。
2）但不是 2pl 允许的每个 cs 时间表。
3）这是我发现的一个定理：如果所有事务都服从 2pl，那么所有可能的交错调度都是可序列化的。
我的问题是，如果 2pl 允许的某些交易时间表是否意味着这些交易的所有可能的交错时间表都是 cs？（这里没有指定所有交易都遵守 2pl）
我对第 2 点感到困惑 bcoz。和定理。