一文讲透微服务下如何保证事务的一致性

 

1. 从本地事务到分布式事务的演变

什么是事务？回答这个问题之前，我们先来看一个经典的场景：支付宝等交易平台的转账。假设小明需要用支付宝给小红转账 100000 元，此时，小明帐号会少 100000 元，而小红帐号会多 100000 元。如果在转账过程中系统崩溃了，小明帐号少 100000 元，而小红帐号金额不变，就会出大问题，因此这个时候我们就需要使用事务了。请参见图 6-1。

这里，体现了事务一个很重要的特性：原子性。事实上，事务有四个基本特性：原子性、一致性、隔离性、持久性。

1. 原子性，即事务内的操作要么全部成功，要么全部失败，不会在中间的某个环节结束。
2. 一致性，即使数据库在一个事务执行之前和执行之后，数据库都必须处于一致性状态。如果事务执行失败，那么需要自动回滚到原始状态，换句话说，事务一旦提交，其他事务查看到的结果一致，事务一旦回滚，其他事务也只能看到回滚前的状态。
3. 隔离性，即在并发环境中，不同的事务同时修改相同的数据时，一个未完成事务不会影响另外一个未完成事务。
4. 持久性，即事务一旦提交，其修改的数据将永久保存到数据库中，其改变是永久性的。

本地事务通过 ACID 保证数据的强一致性。ACID是 Atomic（原子性）、Consistency（一致性）、 Isolation（隔离性）和 Durability（持久性）的缩写 。在实际开发过程中，我们或多或少都有使用到本地事务。

例如，MySQL 事务处理使用到 begin 开始一个事务，rollback 事务回滚，commit 事务确认。这里，事务提交后，通过 redo log 记录变更，通过 undo log 在失败时进行回滚，保证事务的原子性。笔者补充下，使用 Java 语言的开发者都接触过 Spring。Spring 使用 @Transactional 注解就可以搞定事务功能。事实上，Spring 封装了这些细节，在生成相关的 Bean 的时候，在需要注入相关的带有 @Transactional 注解的 bean 时候用代理去注入，在代理中为我们开启提交/回滚事务。请参见图6-2。

随着业务的高速发展，面对海量数据，例如，上千万甚至上亿的数据，查询一次所花费的时间会变长，甚至会造成数据库的单点压力。因此，我们就要考虑分库与分表方案了。

分库与分表的目的在于，减小数据库的单库单表负担，提高查询性能，缩短查询时间。这里，我们先来看下单库拆分的场景。事实上，分表策略可以归纳为垂直拆分和水平拆分。

垂直拆分，把表的字段进行拆分，即一张字段比较多的表拆分为多张表，这样使得行数据变小。一方面，可以减少客户端程序和数据库之间的网络传输的字节数，因为生产环境共享同一个网络带宽，随着并发查询的增多，有可能造成带宽瓶颈从而造成阻塞。另一方面，一个数据块能存放更多的数据，在查询时就会减少 I/O 次数。

水平拆分，把表的行进行拆分。因为表的行数超过几百万行时，就会变慢，这时可以把一张的表的数据拆成多张表来存放。水平拆分，有许多策略，例如，取模分表，时间维度分表等。这种场景下，虽然我们根据特定规则分表了，我们仍然可以使用本地事务。

但是，库内分表，仅仅是解决了单表数据过大的问题，但并没有把单表的数据分散到不同的物理机上，因此并不能减轻 MySQL 服务器的压力，仍然存在同一个物理机上的资源竞争和瓶颈，包括 CPU、内存、磁盘 IO、网络带宽等。

对于分库拆分的场景，它把一张表的数据划分到不同的数据库，多个数据库的表结构一样。此时，如果我们根据一定规则将我们需要使用事务的数据路由到相同的库中，可以通过本地事务保证其强一致性。但是，对于按照业务和功能划分的垂直拆分，它将把业务数据分别放到不同的数据库中。这里，拆分后的系统就会遇到数据的一致性问题，因为我们需要通过事务保证的数据分散在不同的数据库中，而每个数据库只能保证自己的数据可以满足 ACID 保证强一致性，但是在分布式系统中，它们可能部署在不同的服务器上，只能通过网络进行通信，因此无法准确的知道其他数据库中的事务执行情况。请参见图6-3。

此外，不仅仅在跨库调用存在本地事务无法解决的问题，随着微服务的落地中，每个服务都有自己的数据库，并且数据库是相互独立且透明的。那如果服务 A 需要获取服务 B 的数据，就存在跨服务调用，如果遇到服务宕机，或者网络连接异常、同步调用超时等场景就会导致数据的不一致，这个也是一种分布式场景下需要考虑数据一致性问题。请参见图6-4。

总结一下，当业务量级扩大之后的分库，以及微服务落地之后的业务服务化，都会产生分布式数据不一致的问题。既然本地事务无法满足需求，因此分布式事务就要登上舞台。

什么是分布式事务？我们可以简单地理解，它就是为了保证不同数据库的数据一致性的事务解决方案。这里，我们有必要先来了解下 CAP 原则和 BASE 理论。

CAP 原则是 Consistency（一致性）、Availablity（可用性）和 Partition-tolerance（分区容错性）的缩写，它是分布式系统中的平衡理论。在分布式系统中，一致性要求所有节点每次读操作都能保证获取到最新数据；可用性要求无论任何故障产生后都能保证服务仍然可用；分区容错性要求被分区的节点可以正常对外提供服务。

事实上，任何系统只可同时满足其中二个，无法三者兼顾。对于分布式系统而言，分区容错性是一个最基本的要求。那么，如果选择了一致性和分区容错性，放弃可用性，那么网络问题会导致系统不可用。如果选择可用性和分区容错性，放弃一致性，不同的节点之间的数据不能及时同步数据而导致数据的不一致。请参见图 6-5。

此时，BASE 理论针对一致性和可用性提出了一个方案，BASE 是 Basically Available（基本可用）、Soft-state（软状态）和 Eventually Consistent（最终一致性）的缩写，它是最终一致性的理论支撑。简单地理解，在分布式系统中，允许损失部分可用性，并且不同节点进行数据同步的过程存在延时，但是在经过一段时间的修复后，最终能够达到数据的最终一致性。BASE 强调的是数据的最终一致性。相比于 ACID 而言，BASE 通过允许损失部分一致性来获得可用性。

现在，业内比较常用的分布式事务解决方案，包括强一致性的两阶段提交协议，三阶段提交协议，以及最终一致性的可靠事件模式、补偿模式，阿里的 TCC 模式。我们会在后面的章节中详细介绍与实战。

2. 强一致性解决方案

2.1 二阶段提交协议

在分布式系统中，每个数据库只能保证自己的数据可以满足 ACID 保证强一致性，但是它们可能部署在不同的服务器上，只能通过网络进行通信，因此无法准确的知道其他数据库中的事务执行情况。因此，为了解决多个节点之间的协调问题，就需要引入一个协调者负责控制所有节点的操作结果，要么全部成功，要么全部失败。其中，XA 协议是一个分布式事务协议，它有两个角色：事务管理者和资源管理者。这里，我们可以把事务管理者理解为协调者，而资源管理者理解为参与者。
XA 协议通过二阶段提交协议保证强一致性。

二阶段提交协议，顾名思义，它具有两个阶段：第一阶段准备，第二阶段提交。这里，事务管理者（协调者）主要负责控制所有节点的操作结果，包括准备流程和提交流程。

第一阶段，事务管理者（协调者）向资源管理者（参与者）发起准备指令，询问资源管理者（参与者）预提交是否成功。如果资源管理者（参与者）可以完成，就会执行操作，并不提交，最后给出自己响应结果，是预提交成功还是预提交失败。

第二阶段，如果全部资源管理者（参与者）都回复预提交成功，资源管理者（参与者）正式提交命令。如果其中有一个资源管理者（参与者）回复预提交失败，则事务管理者（协调者）向所有的资源管理者（参与者）发起回滚命令。

举个案例，现在我们有一个事务管理者（协调者），三个资源管理者（参与者），那么这个事务中我们需要保证这三个参与者在事务过程中的数据的强一致性。首先，事务管理者（协调者）发起准备指令预判它们是否已经预提交成功了，如果全部回复预提交成功，那么事务管理者（协调者）正式发起提交命令执行数据的变更。请参见图 6-6。

注意的是，虽然二阶段提交协议为保证强一致性提出了一套解决方案，但是仍然存在一些问题。

其一，事务管理者（协调者）主要负责控制所有节点的操作结果，包括准备流程和提交流程，但是整个流程是同步的，所以事务管理者（协调者）必须等待每一个资源管理者（参与者）返回操作结果后才能进行下一步操作。这样就非常容易造成同步阻塞问题。

其二，单点故障也是需要认真考虑的问题。事务管理者（协调者）和资源管理者（参与者）都可能出现宕机，如果资源管理者（参与者）出现故障则无法响应而一直等待，事务管理者（协调者）出现故障则事务流程就失去了控制者，换句话说，就是整个流程会一直阻塞，甚至极端的情况下，一部分资源管理者（参与者）数据执行提交，一部分没有执行提交，也会出现数据不一致性。

此时，读者会提出疑问：这些问题应该都是小概率情况，一般是不会产生的？是的，但是对于分布式事务场景，我们不仅仅需要考虑正常逻辑流程，还需要关注小概率的异常场景，如果我们对异常场景缺乏处理方案，可能就会出现数据的不一致性，那么后期靠人工干预处理，会是一个成本非常大的任务，此外，对于交易的核心链路也许就不是数据问题，而是更加严重的资损问题。

2.2 三阶段提交协议

二阶段提交协议诸多问题，因此三阶段提交协议就要登上舞台了。三阶段提交协议是二阶段提交协议的改良版本，它与二阶段提交协议不同之处在于，引入了超时机制解决同步阻塞问题，此外加入了预备阶段尽可能提早发现无法执行的资源管理者（参与者）并且终止事务，如果全部资源管理者（参与者）都可以完成，才发起第二阶段的准备和第三阶段的提交。否则，其中任何一个资源管理者（参与者）回复执行，或者超时等待，那么就终止事务。总结一下，三阶段提交协议包括：第一阶段预备，第二阶段准备，第二阶段提交。请参见图 6-7。

三阶段提交协议很好的解决了二阶段提交协议带来的问题，是一个非常有参考意义的解决方案。但是，极小概率的场景下可能会出现数据的不一致性。因为三阶段提交协议引入了超时机制，如果出现资源管理者（参与者）超时场景会默认提交成功，但是如果其没有成功执行，或者其他资源管理者（参与者）出现回滚，那么就会出现数据的不一致性。