分布式事务解决方案

分布式事务解决方案

1) 了解本地事务与分布式事务

2) 了解 CAP 理论与 BASE 理论

3) 了解常见分布式事务解决方案

4) 能够通过 Seata 实现分布式事务

5) 能够通过消息队列实现分布式事务

1. 分布式事务解决方案

刚才我们编写的扣减库存与保存订单是在两个服务中存在的，如果扣减库存后订单保存失败了是不会回

滚的，这样就会造成数据不一致的情况，这其实就是我们所说的分布式事务的问题，接下来我们来学习

分布式事务的解决方案。

1.1 本地事务与分布式事务

1.1.1 事务

数据库事务 ( 简称：事务， Transaction) 是指数据库执行过程中的一个逻辑单位，由一个有限的数据库操

作序列构成。

事务拥有以下四个特性，习惯上被称为 ACID 特性：

原子性 (Atomicity) ：事务作为一个整体被执行，包含在其中的对数据库的操作要么全部被执行，要么

都不执行。

一致性 (Consistency) ：事务应确保数据库的状态从一个一致状态转变为另一个一致状态。一致状态是

指数据库中的数据应满足完整性约束。除此之外，一致性还有另外一层语义，就是事务的中间状态不能

被观察到 ( 这层语义也有说应该属于原子性 ) 。

隔离性 (Isolation) ：多个事务并发执行时，一个事务的执行不应影响其他事务的执行，如同只有这一个

操作在被数据库所执行一样。

持久性 (Durability) ：已被提交的事务对数据库的修改应该永久保存在数据库中。在事务结束时，此操

作将不可逆转。

1.1.2 本地事务

起初，事务仅限于对单一数据库资源的访问控制 , 架构服务化以后，事务的概念延伸到了服务中。倘若将

一个单一的服务操作作为一个事务，那么整个服务操作只能涉及一个单一的数据库资源 , 这类基于单个服

务单一数据库资源访问的事务，被称为本地事务 (Local Transaction) 。

北京市昌平区建材城西路金燕龙办公楼一层 电话：400-618-9090 1.1.3 分布式事务

分布式事务指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系

统的不同节点之上 , 且属于不同的应用，分布式事务需要保证这些操作要么全部成功，要么全部失败。本

质上来说，分布式事务就是为了保证不同数据库的数据一致性。

最早的分布式事务应用架构很简单，不涉及服务间的访问调用，仅仅是服务内操作涉及到对多个数据库

资源的访问。

当一个服务操作访问不同的数据库资源，又希望对它们的访问具有事务特性时，就需要采用分布式事务

来协调所有的事务参与者。

对于上面介绍的分布式事务应用架构，尽管一个服务操作会访问多个数据库资源，但是毕竟整个事务还

是控制在单一服务的内部。如果一个服务操作需要调用另外一个服务，这时的事务就需要跨越多个服务

了。在这种情况下，起始于某个服务的事务在调用另外一个服务的时候，需要以某种机制流转到另外一

个服务，从而使被调用的服务访问的资源也自动加入到该事务当中来。下图反映了这样一个跨越多个服

务的分布式事务：

如果将上面这两种场景 ( 一个服务可以调用多个数据库资源，也可以调用其他服务 ) 结合在一起，对此进

行延伸，整个分布式事务的参与者将会组成如下图所示的树形拓扑结构。在一个跨服务的分布式事务

中，事务的发起者和提交均系同一个，它可以是整个调用的客户端，也可以是客户端最先调用的那个服

务。

北京市昌平区建材城西路金燕龙办公楼一层 电话：400-618-9090 较之基于单一数据库资源访问的本地事务，分布式事务的应用架构更为复杂。在不同的分布式应用架构

下，实现一个分布式事务要考虑的问题并不完全一样，比如对多资源的协调、事务的跨服务传播等，实

现机制也是复杂多变。

1.2 分布式事务相关理论

1.2.1 CAP 定理

CAP 定理是在 1998 年加州大学的计算机科学家 Eric Brewer （埃里克 . 布鲁尔）提出，分布式系统有三

个指标

Consistency 一致性

Availability 可用性

Partition tolerance 分区容错性

它们的第一个字母分别是 C 、 A 、 P 。 Eric Brewer 说，这三个指标不可能同时做到。这个结论就叫做

CAP 定理。

分区容错 Partition tolerance

北京市昌平区建材城西路金燕龙办公楼一层 电话：400-618-9090 大多数分布式系统都分布在多个子网络。每个子网络就叫做一个区（ partition ）。分区容错的意思是，

区间通信可能失败。比如，一台服务器放在中国，另一台服务器放在美国，这就是两个区，它们之间可

能无法通信。

上图中， G1 和 G2 是两台跨区的服务器。 G1 向 G2 发送一条消息， G2 可能无法收到。系统设计的时

候，必须考虑到这种情况。

一般来说，分区容错无法避免，因此可以认为 CAP 的 P 总是成立。 CAP 定理告诉我们，剩下的 C 和 A

无法同时做到。

可用性 Availability

Availability 中文叫做 " 可用性 " ，意思是只要收到用户的请求，服务器就必须给出回应。

用户可以选择向 G1 或 G2 发起读操作。不管是哪台服务器，只要收到请求，就必须告诉用户，到底是

v0 还是 v1 ，否则就不满足可用性。

一致性 Consistency

Consistency 中文叫做 " 一致性 " 。意思是，写操作之后的读操作，必须返回该值。

举例来说，某条记录是 v0 ，用户向 G1 发起一个写操作，将其改为 v1 。

北京市昌平区建材城西路金燕龙办公楼一层 电话：400-618-9090 问题是，用户有可能向 G2 发起读操作，由于 G2 的值没有发生变化，因此返回的是 v0 。 G1 和 G2 读

操作的结果不一致，这就不满足一致性了。

为了让 G2 也能变为 v1 ，就要在 G1 写操作的时候，让 G1 向 G2 发送一条消息，要求 G2 也改成 v1 。

一致性和可用性的矛盾

北京市昌平区建材城西路金燕龙办公楼一层 电话：400-618-9090 一致性和可用性，为什么不可能同时成立？答案很简单，因为可能通信失败（即出现分区容错）。

如果保证 G2 的一致性，那么 G1 必须在写操作时，锁定 G2 的读操作和写操作。只有数据同步后，才

能重新开放读写。锁定期间， G2 不能读写，没有可用性。

如果保证 G2 的可用性，那么势必不能锁定 G2 ，所以一致性不成立。

综上所述， G2 无法同时做到一致性和可用性。系统设计时只能选择一个目标。如果追求一致性，那么

无法保证所有节点的可用性；如果追求所有节点的可用性，那就没法做到一致性。

1.2.2 BASE 理论

BASE ：全称： Basically Available( 基本可用 ) ， Soft state （软状态） , 和 Eventually consistent （最终一

致性）三个短语的缩写，来自 ebay 的架构师提出。 BASE 理论是对 CAP 中一致性和可用性权衡的结

果，其来源于对大型互联网分布式实践的总结，是基于 CAP 定理逐步演化而来的。其核心思想是：

既是无法做到强一致性（ Strong consistency ），但每个应用都可以根据自身的业务特点，采用

适当的方式来使系统达到最终一致性（ Eventual consistency ）。

Basically Available( 基本可用 )

什么是基本可用呢？假设系统，出现了不可预知的故障，但还是能用，相比较正常的系统而言：

1. 响应时间上的损失：正常情况下的搜索引擎 0.5 秒即返回给用户结果，而 基本可用 的搜索引擎可以

在 1 秒作用返回结果。

2. 功能上的损失：在一个电商网站上，正常情况下，用户可以顺利完成每一笔订单，但是到了大促期

间，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面。

Soft state （软状态）

什么是软状态呢？相对于原子性而言，要求多个节点的数据副本都是一致的，这是一种 “ 硬状态 ” 。

软状态指的是：允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性，即允许系统

在多个不同节点的数据副本存在数据延时。

Eventually consistent （最终一致性）

系统能够保证在没有其他新的更新操作的情况下，数据最终一定能够达到一致的状态，因此所有客户端

对系统的数据访问最终都能够获取到最新的值。

1.3 分布式事务解决方案

1.3.1 基于 XA 协议的两阶段提交 2PC

首先我们来简要看下分布式事务处理的 XA 规范 ：

北京市昌平区建材城西路金燕龙办公楼一层 电话：400-618-9090 可知 XA 规范中分布式事务有 AP ， RM ， TM 组成：

其中应用程序 (Application Program ，简称 AP) ： AP 定义事务边界（定义事务开始和结束）并访问事务

边界内的资源。

资源管理器 (Resource Manager ，简称 RM) ： Rm 管理计算机共享的资源，许多软件都可以去访问这些

资源，资源包含比如数据库、文件系统、打印机服务器等。

事务管理器 (Transaction Manager ，简称 TM) ：负责管理全局事务，分配事务唯一标识，监控事务的执

行进度，并负责事务的提交、回滚、失败恢复等。

二阶段协议 :

第一阶段 TM 要求所有的 RM 准备提交对应的事务分支，询问 RM 是否有能力保证成功的提交事务分支，

RM 根据自己的情况，如果判断自己进行的工作可以被提交，那就对工作内容进行持久化，并给 TM 回执

OK ；否者给 TM 的回执 NO 。 RM 在发送了否定答复并回滚了已经完成的工作后，就可以丢弃这个事务分

支信息了。

第二阶段 TM 根据阶段 1 各个 RM prepare 的结果，决定是提交还是回滚事务。如果所有的 RM 都 prepare

成功，那么 TM 通知所有的 RM 进行提交；如果有 RM prepare 回执 NO 的话，则 TM 通知所有 RM 回滚自己

的事务分支。

也就是 TM 与 RM 之间是通过两阶段提 交协议进行交互的 .

优点： 尽量保证了数据的强一致，适合对数据强一致要求很高的关键领域。（其实也不能 100% 保证强

一致）

缺点： 实现复杂，牺牲了可用性，对性能影响较大，不适合高并发高性能场景。

1.3.2 TCC 补偿机制

TCC 其实就是采用的补偿机制，其核心思想是：针对每个操作，都要注册一个与其对应的确认和补偿

（撤销）操作。它分为三个阶段：

Try 阶段主要是对业务系统做检测及资源预留

Confirm 阶段主要是对业务系统做确认提交， Try 阶段执行成功并开始执行 Confirm 阶段时，默认

Confirm 阶段是不会出错的。即：只要 Try 成功， Confirm 一定成功。

Cancel 阶段主要是在业务执行错误，需要回滚的状态下执行的业务取消，预留资源释放。

北京市昌平区建材城西路金燕龙办公楼一层 电话：400-618-9090 例如： A 要向 B 转账，思路大概是：

优点： 相比两阶段提交，可用性比较强

缺点： 数据的一致性要差一些。 TCC 属于应用层的一种补偿方式，所以需要程序员在实现的时候多写很

多补偿的代码，在一些场景中，一些业务流程可能用 TCC 不太好定义及处理。

1.3.3 消息最终一致性

消息最终一致性应该是业界使用最多的，其核心思想是将分布式事务拆分成本地事务进行处理，这种思

路是来源于 ebay 。我们可以从下面的流程图中看出其中的一些细节：

基本思路就是：

消息生产方，需要额外建一个消息表，并记录消息发送状态。消息表和业务数据要在一个事务里提交，

也就是说他们要在一个数据库里面。然后消息会经过 MQ 发送到消息的消费方。如果消息发送失败，会

进行重试发送。

消息消费方，需要处理这个消息，并完成自己的业务逻辑。此时如果本地事务处理成功，表明已经处理

成功了，如果处理失败，那么就会重试执行。如果是业务上面的失败，可以给生产方发送一个业务补偿

消息，通知生产方进行回滚等操作。

我们有一个本地方法，里面依次调用

1 、首先在 Try 阶段，要先调用远程接口把 B 和 A 的钱给冻结起来。

2 、在 Confirm 阶段，执行远程调用的转账的操作，转账成功进行解冻。

3 、如果第 2 步执行成功，那么转账成功，如果第二步执行失败，则调用远程冻结接口对应的解冻方法

(Cancel) 。

北京市昌平区建材城西路金燕龙办公楼一层 电话：400-618-9090 生产方和消费方定时扫描本地消息表，把还没处理完成的消息或者失败的消息再发送一遍。如果有靠谱

的自动对账补账逻辑，这种方案还是非常实用的。

优点： 一种非常经典的实现，避免了分布式事务，实现了最终一致性。

缺点： 消息表会耦合到业务系统中，如果没有封装好的解决方案，会有很多杂活需要处理。

2. 基于 Seata 实现分布式事务

2.1 Seata 简介

Seata （原名 Fescar ） 是阿里 18 年开源的分布式事务的框架。 Fescar 的开源对分布式事务框架领域影响

很大。作为开源大户， Fescar 来自阿里的 GTS ，经历了好几次双十一的考验，一经开源便颇受关注。后

来 Fescar 改名为 Seata 。

Fescar 虽然是二阶段提交协议的分布式事务，但是其解决了 XA 的一些缺点 :

单点问题 :

同步阻塞 :Fescar 的二阶段，其再第一阶段的时候本地事务就已经提交释放资源了，不会像 XA 会再

两个 prepare 和 commit 阶段资源都锁住，并且 Fescar,commit 是异步操作，也是提升性能的一大

关键。

数据不一致 : 如果出现部分 commit 失败，那么 fescar-server 会根据当前的事务模式和分支事务的返

回状态的结果来进行不同的重试策略。并且 fescar 的本地事务会在一阶段的时候进行提交，其实单

看数据库来说在 commit 的时候数据库已经是一致的了。

只能用于单一数据库 : Fescar 提供了两种模式， AT 和 MT 。在 AT 模式下事务资源可以是任何支持

ACID 的数据库，在 MT 模式下事务资源没有限制，可以是缓存，可以是文件，可以是其他的等等。

当然这两个模式也可以混用。

同时 Fescar 也保留了接近 0 业务入侵的优点，只需要简单的配置 Fescar 的数据代理和加个注解，加一个

Undolog 表，就可以达到我们想要的目的。

2.2 实现原理

Fescar