二夕说废话の地方

分布式 006——事务

 8015  16 分钟

关于分布式事务你知道哪些？

前言

我们还是从电商系统开始谈起，确实有点俗套，但从业务场景的角度考虑可以更好地解释一些概念。在我们平时网购的过程中，创建的每一笔订单，对于电商平台来说都会涉及到两个核心步骤：一是订单业务采取下订单操作，二是库存业务采取减库存操作。

在实际的后台中，这两个业务通常会运行在不同的服务器上，甚至是运行在不同区域的服务器上，在 2024 年听见“异地多活”已经不是什么新鲜的概念了。但是对于同一笔订单，当且仅当订单操作和减库存操作一致时，才能保证交易的正确性。也就是说一笔订单，只有当上述两个操作都完成，才能算处理成功，否则就是处理失败。

这个问题放在分布式领域，对应的就是分布式事务，下面就一起来详细了解一些关于事务的基础知识。

从事务开始谈起

在深入分布式事务之前，我们先来重新回顾一下什么是事务。

事务（Transaction）提供一种机制，将包含一系列操作的工作序列纳入到一个不可分割的执行单元。只有所有操作均被正确执行才能提交事务；任意一个操作失败都会导致整个事务回滚（Rollback）到之前状态，即所有操作均被取消。简单来说，事务提供了一种机制，使得工作要么全部都不做，要么完全被执行，简单概括就是 all or nothing。

通常情况下，我们所指的事务都是本地事务，也就是运行在单机上的事务。这类事务也就具备 ACID 四大特性，其具体含义如下：

  • A：原子性（Atomicity），事务被视为一个不可分割的原子操作，即事务最终的状态只有两种，全部执行成功和全部不执行，不会停留在中间某个环节。若处理事务的任何一项操作不成功，就会导致整个事务失败。一旦操作失败，所有操作都会被取消（即回滚），使得事务仿佛没有被执行过一样。就好比买一件商品，购买成功时，则给商家付了钱，商品到手；购买失败时，则商品在商家手中，消费者的钱也没花出去。
  • C：一致性（Consistency），是指事务操作前和操作后，数据满足完整性约束，数据库保持一致性状态。比如，用户 A 和用户 B 在银行分别有 200 元和 100 元，总共 300 元。用户 A 给用户 B 转账 100 元，分为两个步骤，从 A 的账户扣除 100 元和对 B 的账户增加 100 元。一致性就是要求上述步骤操作后，最后的结果是用户 A 还有 100 元，用户 B 有 200 元，总共 300 元，而不会出现用户 A 扣除了 100 元，但用户 B 未增加的情况（该情况，用户 A 和 B 均为 100 元，总共 200 元）。
  • I：隔离性（Isolation），事务之间的操作应该相互隔离，一个事务的执行不应该受到其他事务的干扰。并发执行的多个事务应该产生与串行执行相同的结果，以避免数据不一致性和冲突。比如说，消费者购买商品这个事务，是不影响其他消费者购买的。
  • D：持久性（Durability），也被称为永久性，是指一个事务被执行后，那么它对数据库所做的更新就永久地保存下来了。即使发生系统崩溃或宕机等故障，重新启动数据库系统后，只要数据库能够重新被访问，那么一定能够将其恢复到事务完成时的状态。就像消费者在网站上的购买记录，即使换了一台设备，也依然可以查到。

只有在数据操作请求满足上述四个特性的条件下，存储系统才能保证处于正确的工作状态。因此，无论是在传统的集中式存储系统还是在分布式存储系统中，任何数据操作请求都必须满足 ACID 特性。

那么分布式事务是什么呢？顾名思义，就是在分布式系统中运行的事务，由多个本地事务所组成。在分布式系统中，对于事务的处理要复杂的多，这些事务可能来自于不同的机器，不同的地区，或者不同的操作系统。开头所提到的电商处理订单问题，就是一个比较典型的分布式事务。

分布式事务由多个事务组成，因此基本满足 ACID，其中的 C 是强一致性，也就是所有操作均执行成功，才提交最终结果，以保证数据一致性或完整性。但随着分布式系统规模不断扩大，复杂度急剧上升，达成强一致性所需时间周期较长，限定了复杂业务的处理。为了适应复杂业务，出现了 BASE 理论，该理论的一个关键点就是采用最终一致性代替强一致性。

梳理清楚上述的基本概念之后，接下来就一起看看如何实现一个简单的分布式事务。

实现分布式事务

在探讨如何实现分布式事务之前，我们要了解为什么要有分布式事务？实际上，分布式事务主要是解决在分布式环境下，组合事务的一致性问题。实现分布式事务有以下 3 种基本方法：

  • 基于 XA 协议的二阶段提交协议方法；
  • 三阶段提交协议方法；
  • 基于消息的最终一致性方法。

其中，基于 XA 协议的二阶段提交协议方法和三阶段提交协议方法，采用了强一致性，遵从 ACID。基于消息的最终一致性方法，采用了最终一致性，遵从 BASE 理论。

基于 XA 协议的二阶段提交方法

XA 是一个分布式事务协议，规定了事务管理器和资源管理器接口，使得应用程序能够通过事务管理器来管理分布式环境下的多个资源，通常是数据库。由此可以看出，XA 协议主要包括事务管理器和本地资源管理器两个部分。

XA 实现分布式事务的原理，比较类似于分布式互斥博客中所介绍的集中式算法：事务管理器相当于协调者，负责各个本地资源的提交和回滚；而资源管理器就是分布式事务的参与者，通常由数据库实现，比如 Oracle、DB2 等商业数据库都实现了 XA 接口。

基于 XA 协议的二阶段提交方法中，二阶段提交协议（Two-phase Commit Protocol，2PC），用于保证分布式系统中事务提交时的数据一致性，是 XA 在全局事务中用于协调多个资源的机制。

那么 2PC 是如何保证分布在不同节点上的分布式事务的一致性呢？为了做到这一点，会需要引入一个协调者来管理所有的节点，并确保这些节点能够正确提交操作结果，若提交失败则放弃事务。接下来，我们看看两阶段提交协议的具体过程。

两阶段提交协议的执行过程，分为投票（Voting）和提交（Commit）两个阶段。

首先，我们看一下第一阶段投票：在这一阶段，协调者（Coordinator，即事务管理器）会向事务的参与者，也就是本地资源管理器，发起执行操作的 CanCommit 请求，并等待参与者的响应。参与者接收到请求后，会执行请求中的事务操作，将操作信息记录到事务日志中但不提交，也就是暂时不会修改数据库中的数据，待参与者执行成功，则向协调者发送“Yes”消息，表示同意操作；若不成功，则发送“No”消息，表示终止操作。

当所有的参与者都返回了操作结果（Yes 或 No 消息）后，系统进入了第二阶段提交阶段（也可以称为，执行阶段）。在提交阶段，协调者会根据所有参与者返回的信息向参与者发送 DoCommit（提交）或 DoAbort（取消）指令。具体规则如下：

  • 若协调者从参与者那里收到的都是“Yes”消息，则向参与者发送“DoCommit”消息。参与者收到“DoCommit”消息后，完成剩余的操作（比如修改数据库中的数据）并释放资源（整个事务过程中占用的资源），然后向协调者返回“HaveCommitted”消息；
  • 若协调者从参与者收到的消息中包含“No”消息，则向所有参与者发送“DoAbort”消息。此时投票阶段发送“Yes”消息的参与者，则会根据之前执行操作时的事务日志对操作进行回滚，就好像没有执行过请求操作一样，然后所有参与者会向协调者发送“HaveCommitted”消息；
  • 协调者接收到来自所有参与者的“HaveCommitted”消息后，就意味着整个事务结束了。

这么说可能比较抽象，接下来我们以一个具体的案例来进行讲解。假设用户 A 想要在某宝上购买 100 件 T 恤，这中间可能会涉及到很多的业务流程，但重点聚焦于下单和减少库存这两个操作。

第一阶段：订单系统接收到来自于用户 A 的下单操作，会将与用户 A 有关的订单数据库锁住，准备好增加一条关于用户 A 购买 100 件 T 恤的信息，并将同意消息“Yes”回复给协调者。但库存系统由于 T 恤库存不足，出货失败，因此向协调者回复了一个终止消息“No”。

2pc-01

第二阶段：由于库存系统操作不成功，因此，协调者就会向订单系统和库存系统发送“DoAbort”消息。订单系统接收到“DoAbort”消息后，将系统内的数据退回到没有用户 A 购买 100 件 T 恤的版本，并释放锁住的数据库资源。订单系统和库存系统完成操作后，向协调者发送“HaveCommitted”消息，表示完成了事务的撤销操作。

至此，用户 A 购买 100 件 T 恤这一事务已经结束，用户 A 购买失败。

2pc-02

由上述流程可以看出，二阶段提交的算法思路可以概括为：协调者向参与者下发请求事务操作，参与者接收到请求后，进行相关操作并将操作结果通知协调者，协调者根据所有参与者的反馈结果决定各参与者是要提交操作还是撤销操作。

虽然基于 XA 的二阶段提交算法尽量保证了数据的强一致性，而且实现成本低，但依然有些不足。主要有以下三个问题：

  • 同步阻塞问题：二阶段提交算法在执行过程中，所有参与节点都是事务阻塞型的。也就是说，当本地资源管理器占有临界资源时，其他资源管理器如果要访问同一临界资源，会处于阻塞状态。因此，基于 XA 的二阶段提交协议不支持高并发场景。
  • 单点故障问题：该算法类似于集中式算法，一旦事务管理器发生故障，整个系统都处于停滞状态。尤其是在提交阶段，一旦事务管理器发生故障，资源管理器会由于等待管理器的消息，而一直锁定事务资源，导致整个系统被阻塞。
  • 数据不一致问题：在提交阶段，当协调者向所有参与者发送“DoCommit”请求时，如果发生了局部网络异常，或者在发送提交请求的过程中协调者发生了故障，就会导致只有一部分参与者接收到了提交请求并执行提交操作，但其他未接到提交请求的那部分参与者则无法执行事务提交。于是整个分布式系统便出现了数据不一致的问题。

三阶段提交方法

三阶段提交协议（Three-phase Commit Protocol，3PC），是对二阶段提交（2PC）的改进。为了更好地处理两阶段提交的同步阻塞和数据不一致问题，三阶段提交引入了超时机制和准备阶段。

  • 与 2PC 只是在协调者引入超时机制不同，3PC 同时在协调者和参与者中引入了超时机制。如果协调者或参与者在规定的时间内没有接收到来自其他节点的响应，就会根据当前的状态选择提交或者终止整个事务，从而减少了整个集群的阻塞时间，在一定程度上减少或减弱了 2PC 中出现的同步阻塞问题。
  • 在第一阶段和第二阶段中间引入了一个准备阶段，或者说把 2PC 的投票阶段一分为二，也就是在提交阶段之前，加入了一个预提交阶段。在预提交阶段尽可能排除一些不一致的情况，保证在最后提交之前各参与节点的状态是一致的。

于是，三阶段提交协议就有 CanCommit、PreCommit、DoCommit 三个阶段，下面我们来看一下这个三个阶段。

第一，CanCommit 阶段

协调者向参与者发送请求操作，也就是 CanCommit 请求，询问参与者是否可以执行事务提交操作，然后等待参与者的响应；参与者收到 CanCommit 请求之后，回复 Yes，表示可以顺利执行事务；否则回复 No。

3PC 的 CanCommit 阶段与 2PC 的 Voting 阶段相比：

  • 比较类似的点在于：协调者均需要向参与者发送请求操作（CanCommit 请求），询问参与者是否可以执行事务提交操作，然后等待参与者的响应。参与者收到 CanCommit 请求之后，回复 Yes，表示可以顺利执行事务；否则回复 No；
  • 不同之处在于：2PC 中，在投票阶段，若参与者可以执行事务，会将操作信息记录到事务日志中但不提交，并返回结果给协调者。但在 3PC 中，在 CanCommit 阶段，参与者仅会判断是否可以顺利执行事务，并返回结果。而操作信息记录到事务日志，但不提交的操作由第二阶段预提交阶段执行

CanCommit 阶段不同节点之间的事务请求成功和失败的流程，如下所示：

3pc-01

当协调者接收到所有参与者回复的消息后，进入预提交阶段，也就是 PreCommit 阶段。

第二，PreCommit 阶段

协调者根据参与者的回复情况，来决定是否可以进行 PreCommit 操作。

  • 如果所有参与者回复的都是“Yes”，那么协调者就会执行事务的预执行；
  • 协调者向参与者发送 PreCommit 请求，进入预提交阶段；
  • 参与者接收到 PreCommit 请求后执行事务操作，并将 Undo 和 Redo 信息记录到事务日志中；
  • 如果参与者成功执行了事务操作，则返回 ACK 响应，同时开始等待最终指令。
  • 假如任何一个参与者向协调者发送了“No”消息，或者等待超时之后，协调者都没有收到参与者的响应，就执行中断事务的操作；
  • 协调者会向所有参与者发送“Abort”消息；
  • 参与者收到“Abort”消息之后，或超时后仍未收到协调者的消息，则会执行事务的中断操作。

预提交阶段，不同节点上事务执行成功和失败的流程，如下所示：

3pc-02

预提交阶段保证了在最后提交阶段（DoCommit 阶段）之前所有参与者的状态是一致的。

第三，DoCommit 阶段

DoCommit 阶段进行真正的事务提交，根据 PreCommit 阶段协调者发送的消息，进入执行提交阶段或事务中断阶段。

  • 执行提交阶段：

    • 若协调者接收到所有参与者发送的 Ack 响应，则向所有参与者发送 DoCommit 消息，开始执行阶段；
    • 参与者接收到 DoCommit 消息之后，正式提交事务。完成事务提交之后，释放所有锁住的资源，并向协调者发送 Ack 响应；
    • 协调者接收到所有参与者的 Ack 响应之后，完成事务。

  • 事务中断阶段：

    • 协调者向所有参与者发送 Abort 请求；
    • 参与者接收到 Abort 消息之后，利用其在 PreCommit 阶段记录的 Undo 信息执行事务的回滚操作，释放所有锁住的资源，并向协调者发送 Ack 消息；
    • 协调者接接收到参与者反馈的 Ack 消息之后，执行事务的中断，并结束事务。

    执行阶段不同节点上事务执行成功和失败、事务中断的流程，如下图所示：

    3pc-03

3PC 协议在协调者和参与者均引入了超时机制。即当参与者在预提交阶段向协调者发送 Ack 消息后，如果长时间没有得到协调者的响应，在默认情况下，参与者会自动将超时的事务进行提交，从而减少整个集群的阻塞时间，在一定程度上减少或减弱了 2PC 中出现的同步阻塞问题。

但三阶段提交仍然存在数据不一致的情况，比如在 PreCommit 阶段，部分参与者已经接受到 ACK 消息进入执行阶段，但部分参与者与协调者网络不通，导致接收不到 ACK 消息，此时接收到 ACK 消息的参与者会执行任务，未接收到 ACK 消息且网络不通的参与者无法执行任务，最终导致数据不一致。

基于消息的最终一致性方法

2PC 和 3PC 核心思想均是以集中式的方式实现分布式事务，这两种方法都存在两个共同的缺点，一是，同步执行，性能差；二是，数据不一致问题。为了解决这两种问题，通过分布式消息来确保事务最终一致性的方案便出现咯。

最终一致性的思想就是：将需要分布式处理的事务通过消息或者日志的方式异步执行，消息或日志可以存到本地文件、数据库或消息队列中，再通过业务规则进行失败重试。这个案例，就是使用基于分布式消息的最终一致性方案解决了分布式事务的问题。

基于分布式消息的最终一致性方案的事务处理，引入了一个消息中间件，用于在多个应用之间进行消息传递。比如可以采用 RocketMQ 机制来支持消息事务。

基于消息中间件协调多个节点分布式事务执行操作的示意图，如下所示：

final-01

仍然以网上购物为例。假设用户 A 在某电商平台下了一个订单，需要支付 50 元，发现自己的账户余额共 150 元，就使用余额支付，支付成功之后，订单状态修改为支付成功，然后通知仓库发货。

在该事件中，涉及到了订单系统、支付系统、仓库系统，这三个系统是相互独立的应用，通过远程服务进行调用。

final-02

根据基于分布式消息的最终一致性方案，用户 A 通过终端手机首先在订单系统上操作，通过消息队列完成整个购物流程。然后整个购物的流程如下所示。

final-03

  1. 订单系统把订单消息发给消息中间件，消息状态标记为“待确认”；
  2. 消息中间件收到消息后，进行消息持久化操作，即在消息存储系统中新增一条状态为“待发送”的消息；
  3. 消息中间件返回消息持久化结果（成功 / 失败），订单系统根据返回结果判断如何进行业务操作。失败，放弃订单，结束（必要时向上层返回失败结果）；成功，则创建订单；
  4. 订单操作完成后，把操作结果（成功 / 失败）发送给消息中间件；
  5. 消息中间件收到业务操作结果后，根据结果进行处理：失败，删除消息存储中的消息，结束；成功，则更新消息存储中的消息状态为“待发送（可发送）”，并执行消息投递；
  6. 如果消息状态为“可发送”，则 MQ 会将消息发送给支付系统，表示已经创建好订单，需要对订单进行支付。支付系统也按照上述方式进行订单支付操作；
  7. 订单系统支付完成后，会将支付消息返回给消息中间件，中间件将消息传送给订单系统。若支付失败，则订单操作失败，订单系统回滚到上一个状态，MQ 中相关消息将被删除；若支付成功，则订单系统再调用库存系统，进行出货操作，操作流程与支付系统类似；

在上述过程中，可能会产生如下异常情况，其对应的解决方案为：

  1. 订单消息未成功存储到 MQ 中，则订单系统不执行任何操作，数据保持一致；
  2. MQ 成功将消息发送给支付系统（或仓库系统），但是支付系统（或仓库系统）操作成功的 ACK 消息回传失败（由于通信方面的原因），导致订单系统与支付系统（或仓库系统）数据不一致，此时 MQ 会确认各系统的操作结果，删除相关消息，支付系统（或仓库系统）操作回滚，使得各系统数据保持一致；
  3. MQ 成功将消息发送给支付系统（或仓库系统），但是支付系统（或仓库系统）操作成功的 ACK 消息回传成功，订单系统操作后的最终结果（成功或失败）未能成功发送给 MQ，此时各系统数据可能不一致，MQ 也需确认各系统的操作结果，若数据一致，则更新消息；若不一致，则回滚操作、删除消息。

基于分布式消息的最终一致性方案采用消息传递机制，并使用异步通信的方式，避免了通信阻塞，从而增加系统的吞吐量。同时，这种方案还可以屏蔽不同系统的协议规范，使其可以直接交互。

在不需要请求立即返回结果的场景下，这些特性就带来了明显的通信优势，并且通过引入消息中间件，实现了消息生成方（如上述的订单系统）本地事务和消息发送的原子性，采用最终一致性的方式，只需保证数据最终一致即可，一定程度上解决了二阶段和三阶段方法要保证强一致性而在某些情况导致的数据不一致问题。

可以看出，分布式事务中，当且仅当所有的事务均成功时整个流程才成功。所以，分布式事务的一致性是实现分布式事务的关键问题，目前来看还没有一种很简单、完美的方案可以应对所有场景。

总结

本节内容从事务的 ACID 特性出发，介绍了分布式事务的概念、特征，以及如何实现分布式事务。在关于如何实现分布式的部分，以网购为例，介绍了常见的三种实现方式，即基于 XA 协议的二阶段提交方法，三阶段方法以及基于分布式消息的最终一致性方法。

二阶段和三阶段方法是维护强一致性的算法，它们针对刚性事务，实现的是事务的 ACID 特性。而基于分布式消息的最终一致性方案更适用于大规模分布式系统，它维护的是事务的最终一致性，遵循的是 BASE 理论，因此适用于柔性事务。

在分布式系统的设计与实现中，分布式事务是不可或缺的一部分。可以说，没有实现分布式事务的分布式系统，不是一个完整的分布式系统。分布式事务的实现过程看似复杂，但将方法分解剖析后，就会发现分布式事务的实现是有章可循的。

扩展：BASE 理论

在最后咱扩展一点关于 BASE 理论的基础知识。BASE 理论包括基本可用（Basically Available）、柔性状态（Soft State）和最终一致性（Eventual Consistency）。

  • 基本可用：分布式系统出现故障的时候，允许损失一部分功能的可用性，保证核心功能可用。比如，某些电商 618 大促的时候，会对一些非核心链路的功能进行降级处理。
  • 柔性状态：在柔性事务中，允许系统存在中间状态，且这个中间状态不会影响系统整体可用性。比如，数据库读写分离，写库同步到读库（主库同步到从库）会有一个延时，其实就是一种柔性状态。
  • 最终一致性：事务在操作过程中可能会由于同步延迟等问题导致不一致，但最终状态下，所有数据都是一致的。

BASE 理论为了支持大型分布式系统，通过牺牲强一致性，保证最终一致性，来获得高可用性，是对 ACID 原则的弱化。ACID 与 BASE 是对一致性和可用性的权衡所产生的不同结果，但二者都保证了数据的持久性。ACID 选择了强一致性而放弃了系统的可用性。与 ACID 原则不同的是，BASE 理论保证了系统的可用性，允许数据在一段时间内可以不一致，最终达到一致状态即可，也即牺牲了部分的数据一致性，选择了最终一致性。

具体到今天的三种分布式事务实现方式，二阶段提交、三阶段提交方法，遵循的是 ACID 原则，而消息最终一致性方案遵循的就是 BASE 理论。