如何在分布式事务期间锁定对象

Question

我一直在看微服务和分布式事务。大多数文章都谈到了两阶段提交或Saga模式，但没有详细说明对象是如何被锁定的，这样当事务没有完成时，其他人就不能访问该数据。

如果我有一个客户服务和一个订单服务，我发起一个请求来锁定客户的资金，直到订单得到处理。在分布式系统中，这是如何实现的。

在数据库中，是否可以显式锁定一行，然后另一个请求去解锁该行，或者这是使用客户表上的锁定字段实现的，第一个事务将其设置为锁定，一旦订单完成，它返回并将其设置为解锁或清空该行？

如果有一些代码样本的例子，这将是伟大的

Answer 1

在微观服务世界中，事务边界在服务内。服务依赖于最终的一致性。因此，在您的示例中，订单服务将发送一个请求（同步或异步，取决于应用程序语义和规模要求），如从客户y中为订单z扣除x金额。

客户服务将对事务中的客户记录执行操作，并向客户返回响应，例如订单 z 成功处理或订单 z 处理失败。

然后，订单服务可以根据收到的响应触发订单的确认/失败过程。

应用程序通常在可用性和强酸一致性之间进行选择。大多数基于微服务的场景需要可用性和高可伸缩性，而不是强一致性，这意味着服务之间的通信是异步的，最终达到一致的状态。

Answer 2

大多数文章都讨论 2 阶段提交或 Saga 模式，但没有详细介绍对象是如何锁定的，因此当事务未完成时，其他人无法访问该数据。

2PC定义为阻塞。这意味着，如果管理2PC事务的事务管理器关闭，则无法解析2PC。那么事务管理器就是一个单点故障。如果你确信一个失败的事务管理器被重新启动，那么即使是2PC协议也被认为是阻塞的。你就是事务管理器可用的保证，并且解决方案不会被阻塞。

然后2PC使用锁。它们需要作为协议的基本要素。事务管理器与参与者 - 资源进行通信。参与者是数据库。当 2PC 开始运行时，对 prepare 的调用意味着数据库对参与事务的所有行进行持久锁定。当事务管理器调用提交时，将释放此锁。请务必了解 2PC 之前的事务处于动态状态（而不是持久性）。它存储在内存中。调用 prepare 后，事务状态将永久存储，直到调用 commit 为止（此时协议可能会被不可用的事务管理器阻止 - 锁是持久的，系统等待事务管理器释放它）。

这是从 2PC 的角度来看锁定。但是从数据库的角度来看，存在事务锁。当您更新数据库中的行时，事务正在进行中（存储在内存中）。此时，数据库需要确保并发更新不会损坏数据。一种方法是锁定行并且不允许并发更新。但是，在这些情况下，大多数数据库不会锁定行（默认情况下，依赖于隔离级别），因为它们使用快照隔离（MVCC，https://en.wikipedia.org/wiki/Snapshot_isolation）。这尤其意味着该行被乐观地锁定，数据库允许其他事务更新该行。

但是！2PC准备不能被乐观地处理。当数据库回复“OK”以准备来自事务管理器的请求时，该行被锁定。

另外，您无法手动管理此锁定。如果您试图这样做，则会破坏2PC的一致性保证。

如您的示例，有一个客户服务和一个订单服务。当 2PC 事务跨越两个服务时。然后，客户更新数据库，订单服务也会更新数据库。数据库中仍有正在运行的正在处理的事务。然后请求完成，事务管理器命令正在进行的事务提交。它运行2PC。它调用客户服务数据库事务的准备，然后调用订单服务事务，然后调用提交。

如果您使用saga模式，则saga跨越两个服务。从事务的角度来看，客户服务创建一个数据库中的事务，并立即提交。然后，呼叫转到订单服务，在那里也会发生同样的情况。当请求完成时，传奇会检查一切是否正常。当发生故障时，将调用补偿回调。

从易用性的角度来看，失败是“麻烦”。对于 saga，您需要在回调方法中自行维护故障解决方案。对于 2PC，故障解决方案通过回滚调用自动处理。

注意：我试图在这里总结2PC：https://developer.jboss.org/wiki/TwoPhaseCommit2PC我不确定解释是否足够理解，但你可以试着检查一下。你可以让我知道那里有什么错误的解释。谢谢