在当今世界，数据正在以惊人的速度增长。单台计算机的存储容量是有限的，因此需要将数据分布在多台机器或数据库上，这种技术被称为分布式技术。

互联网大厂中很多系统都在采用微服务架构。在这种架构中，每个微服务都管理自己的数据库。如果需要在这些数据库中添加或修改数据，就需要调用该数据库所负责的微服务。

将数据分布在多台机器上会带来一系列挑战。对于单体系统来说，关系数据库如Postgres、MySQL等本身就提供ACID（原子性、一致性、隔离性、持久性）属性。

同样的情况并不适用于分片数据库或分布在微服务中的数据。在本文中，我们将了解处理分布式事务时的原子性。我们将会看到一个名为两阶段提交（2-Phase Commit）的协议，它能帮助我们实现这一点。那么，让我们开始吧。

单体系统

让我们先以一个简单的单体银行应用程序为例。应用程序负责处理用户的银行交易，该系统会与一个单一数据库进行增删改查。

当用户A向用户B转账时，我们需要确保以下几点：

1. 如果交易成功，用户B的账户会增加余额，用户A的账户会减少相应的余额。
2. 交易完成后，数据库服务器可能会崩溃。然而，它必须能恢复到崩溃前的状态。
3. 交易可能由于多种原因失败。例如：用户A可能没有足够的余额。在这种情况下，两个用户的账户都不应更新。
4. 交易完成后，数据库需要处于一致的状态。例如：在用户A扣减之前，用户B不应收到记入的金额。

用户A向用户B转账20美元：

交易后的可能状态：

如果您使用的是关系型数据库，它将保证上述所有四点。关系数据库使用事务来实现这几点。事务是一个抽象概念，它封装了一组操作。它会保证所有操作要么全部成功，要么全部不执行，这就是事物的原子性。

简单来说，事务是一组数据库可以执行的SQL语句。数据库执行每个SQL语句。如果出现故障，它将中止事务。当事务被中止时，底层数据不会发生变化。从状态的角度来看，相当于没有执行任何语句。

如果所有语句都执行，事务将被提交。一旦事务提交，底层数据将被修改并持久化。

对于上述例子，数据库事务将包括以下语句：

Begin
update set balance = balance + 20 where user = ‘B’;
update set balance = balance - 20 where user = ‘A’;
Commit

假设用户A和B的初始余额分别是40美元和60美元。在执行上述事务时，有以下可能性：

• 成功 - 在这种情况下，事务将被提交。用户A的余额将为20美元，用户B的余额将为80美元。如果数据库在此后崩溃，恢复后也会回到这个状态。
• 失败 - 如果在更新用户A的余额时发生故障，数据库将中止事务，并回滚所有更改。用户A和B的余额都不会被改变，也就是说用户A余额仍然是40美元，用户B余额仍然是60美元。

数据库分片

我们现在决定扩展我们的数据库，以满足越来越多的客户需求。数据分布在多个数据库服务器（实例）上。因此，用户A和用户B的数据库记录可能在不同的实例中。

在这种情况下，我们还能保证原子性吗？答案是不能，在处理多个数据库服务器时，保证分布式事物的原子性则落在应用程序的开发者身上了。

以上面用户A向B转账20美元为例。我们将不得不在两个独立的MySQL上执行这两个SQL查询。如果其中一个SQL查询失败，将导致状态不一致。我们希望避免这种不一致状态。

我们必须确保要么事务成功完成，要么失败全部不执行。我们不希望将事务中途留在不一致的状态。下面要介绍的两阶段提交（2-Phase Commit）就是用来保证这一点的。

两阶段提交（2-Phase Commit）

我们现在来看一下两阶段协议的工作原理。我们引入一个新的东东，称为事务协调器（Transaction Coordinator）。它的作用是协调事务的提交部分。管理单个事务的其他服务器称为参与者（Participants）。

在我们的例子中，我们有两个事务Txn Credit和Txn Debit。Txn Credit在分片A上运行，Txn Debit在分片B上运行。客户端启动这两个事务并将它们发送到两个分片。下图说明了这个过程。两个数据库服务器开始执行事务。

稍后，客户端向事务协调器发送提交消息。事务提交现在被事务协调器分为两个阶段。

在第一阶段，RequestCommit消息被发送到所有参与服务器。每个服务器必须对该消息做出响应，返回OK或FAIL消息。如果服务器能够成功执行事务，则返回OK消息。如果在执行期间出现任何错误，则返回FAIL消息。例如：如果在借记事务中账户余额变为负数。

事务协调器等待所有服务器的响应。一旦收到响应，它将决定是提交还是中止事务。这成为提交的第二阶段。只有在每个服务器都回复OK消息时，事务才会被提交。如果至少有一个服务器返回FAIL消息，事务将被中止。

下图显示了每个服务器都返回OK消息的情况。每个其他服务器收到协调器的提交消息，事务成功。

在FAIL消息的情况下，事务协调器向所有参与者发送中止消息。结果，参与者回滚各自的事务。

上述过程确保了分布式事务的原子性。事务要么在所有服务器上提交，要么在所有服务器上回滚。但不会中途留在不一致的状态。不存在一个账户被记入而另一个账户未被扣减的情况。

两阶段提交的缺点

我们现在来探讨两阶段提交的缺点。以下是使用两阶段提交在分布式系统中的主要缺点：

• 延迟：正如我们所见，事务协调器等待所有参与服务器的响应，然后进行提交的第二阶段。这增加了延迟，客户端可能会感受到执行的缓慢。因此，两阶段提交并不适合对性能要求高的应用程序。
• 单点故障：事务协调器有时会成为单点故障。在事务协调器向所有参与者发送提交消息之前，它可能会宕机。在这种情况下，参与者上运行的所有事务将进入阻塞状态。它们只有在协调器恢复并发送提交信号后才会提交。
• 参与者依赖性：一个慢速的参与者会影响其他参与者的性能。总事务时间与最慢服务器的时间成正比。如果事务在单个服务器上失败，则必须在所有其他服务器上回滚。这可能会导致资源浪费。

以上所有2PC的缺点都可以通过Saga模式来克服。Saga模式依赖于最终一致性来处理分布式事务。我们将在后面的文章中探讨这种模式。