总是听别人说分布式事务，在面试中也被问到过几次，但依旧对分布式事务不太了解。而最近考虑换工作，所以想把这块深入的学习一下，本文作为学习的备忘录，在此分享给大家。如有错误欢迎指正！

 

理论基础

在学习分布式事务之前，我们先了解一下分布式事务的理论基础，这样有助于我们更好的理解和实践现有的分布式事务解决方案。

 

本地事务

本地事务（数据库本地事务）中的四大特性ACID（Atomicity、Consistency、Isolation、Durability）:

• 原子性(Atomicity)：一个事务(transaction)中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。
• 一致性(Consistency)：在事务开始之前和事务结束以后，数据库的完整性没有被破坏。这表示写入的资料必须完全符合所有的预设约束、触发器、级联回滚等。
• 隔离性(Isolation)：数据库允许多个并发事务同时对其数据进行读写和修改的能力，隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。事务隔离分为不同级别，包括未提交读（Read uncommitted）、提交读（read committed）、可重复读（repeatable read）和串行化（Serializable）。
• 持久性(Durability)：事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。

 

分布式事务

什么是分布式事务

分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。简单的说，本地事务是解决单个数据源上的数据操作的一致性问题，分布式事务则是为了解决跨越多个数据源上数据操作的一致性问题。

分布式事务产生的原因

从上面本地事务来看，我们可以看为两块，一个是service产生多个节点，另一个是resource产生多个节点。

 

随着互联网快速发展，微服务架构模式正在被大规模的使用，单体应用会被拆分为若干个功能简单、松耦合的服务。举个简单的例子，一个公司之内，用户的资产可能分为好多个部分，比如余额，积分，优惠券等等。余额，积分，优惠券三个服务部署在不同的机器上，由于扣余额、加积分、扣优惠券三个操是在三台服务器上，这就是service产生多个节点。

同样的，互联网发展得太快了，Mysql一般来说装千万级的数据就得进行分库分表，这样会导致某个业务需要操作的数据库表示分布在不同的数据源上的，这就是resource产生多个节点。

 

CAP理论

CAP（Consistency、Availability、Partition Tolerance）定理，又被叫作布鲁尔定理。对于设计分布式系统的架构师来说，CAP就是入门理论。

• 一致性(Consistency)：所有数据库集群节点在同一时间点看到的数据完全一致，即所有节点能实时保持数据同步。
• 可用性(Availability)：读写操作永远是成功的。即服务一直是可用的，即使集群一部分节点故障，集群整体还能正常响应客户端的读写请求。
• 分区容错性(Partition Tolerance)：尽管系统中有任意的信息丢失或故障，系统仍在继续运行。以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。。

熟悉CAP的人都知道，三者不能共有，为什么三者不能共存呢？因为在分布式系统中，网络无法100%可靠，分区其实是一个必然现象，如果我们选择了CA而放弃了P，那么当发生分区现象时，为了保证一致性，这个时候必须拒绝请求，但是A又不允许，所以分布式系统理论上不可能选择CA架构，只能选择CP或者AP架构。对于CP来说，放弃可用性，追求一致性和分区容错性，我们的zookeeper其实就是追求的强一致。对于AP来说，放弃一致性(这里说的一致性是强一致性)，追求分区容错性和可用性，这是很多分布式系统设计时的选择，后面的BASE也是根据AP来扩展。

 

关于CAP的讲解可以去看一下阮一峰的—CAP 定理的含义

 

BASE理论

BASE是Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）三个短语的缩写。

• 基本可用：分布式系统在出现故障时，允许损失部分可用功能，保证核心功能可用。
• 软状态：允许系统中存在中间状态，这个状态不影响系统可用性，这里指的是CAP中的不一致。
• 最终一致：最终一致是指经过一段时间后，所有节点数据都将会达到一致。

 

BASE理论是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的总结， 是基于CAP定理逐步演化而来的。BASE理论的核心思想是：即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。

 

BASE理论面向的是大型高可用可扩展的分布式系统，和传统的事物ACID特性是相反的，它完全不同于ACID的强一致性模型，而是通过牺牲强一致性来获得可用性，并允许数据在一段时间内是不一致的，但最终达到一致状态。但同时，在实际的分布式场景中，不同业务单元和组件对数据一致性的要求是不同的，因此在具体的分布式系统架构设计过程中，ACID特性和BASE理论往往又会结合在一起。

 

关于BASE的讲解可以去看一下—分布式理论(二)——Base 理论

 

柔性事务

不同于ACID的刚性事务，在分布式场景下基于BASE理论，就出现了柔性事务的概念。要想通过柔性事务来达到最终的一致性，就需要依赖于一些特性，这些特性在具体的方案中不一定都要满足，因为不同的方案要求不一样；但是都不满足的话，是不可能做柔性事务的。

 

可见性(对外可查询)

在分布式事务执行过程中，如果某一个步骤执行出错，就需要明确的知道其他几个操作的处理情况，这就需要其他的服务都能够提供查询接口，保证可以通过查询来判断操作的处理情况。

为了保证操作的可查询，需要对于每一个服务的每一次调用都有一个全局唯一的标识，可以是业务单据号（如订单号）、也可以是系统分配的操作流水号（如支付记录流水号）。除此之外，操作的时间信息也要有完整的记录。

 

幂等操作

幂等性，其实是一个数学概念。幂等函数，或幂等方法，是指可以使用相同参数重复执行，并能获得相同结果的函数。推荐阅读：服务高可用：幂等性设计。

f(f(x)) = f(x)

在编程中一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同。也就是说，同一个方法，使用同样的参数，调用多次产生的业务结果与调用一次产生的业务结果相同。这一个要求其实也比较好理解，因为要保证数据的最终一致性，很多解决防范都会有很多重试的操作，如果一个方法不保证幂等，那么将无法被重试。幂等操作的实现方式有多种，如在系统中缓存所有的请求与处理结果、检测到重复操作后，直接返回上一次的处理结果等。

 

分布式事务解决方案

有了上面的理论基础后，这里开始介绍几种常见的分布式事务的解决方案。

 

是否真的要分布式事务

在说方案之前，首先你一定要明确你是否真的需要分布式事务？上面说过出现分布式事务的两个原因，其中一个原因是微服务架构的使用。所以在使用分布式事务之前，可能需要去思考一下自己的设计是否恰当，千万不要因为追求某些设计，而引入不必要的成本和复杂度。

 

如果你确定需要引入分布式事务可以看看下面几种常见的方案。

 

基于XA协议的两阶段提交方案

XA是X/Open CAE Specification (Distributed Transaction Processing)模型中定义的TM（Transaction Manager）与RM（Resource Manager）之间进行通信的接口。

 

在XA规范中，数据库充当RM角色，应用需要充当TM的角色，即生成全局的txId，调用XAResource接口，把多个本地事务协调为全局统一的分布式事务。

 

二阶段提交是XA的标准实现。它将分布式事务的提交拆分为2个阶段：prepare和commit/rollback。2PC模型中，在prepare阶段需要等待所有参与子事务的反馈，因此可能造成数据库资源锁定时间过长，不适合并发高以及子事务生命周长较长的业务场景。两阶段提交这种解决方案属于牺牲了一部分可用性来换取的一致性。

优点

尽量保证了数据的一致性，实现成本低，在各大主流数据库都有自己的实现

缺点

• 要求数据库对XA的支持，如果遇到不支持XA（或支持得不好，如MySQL5.7以前的版本）的数据库，则不能使用。

• 受协议本身的约束，事务资源（数据记录、数据库连接）的锁定周期长，不适合并发高以及子事务生命周长较长的业务场景。
• 可使用已经落地的基于XA的分布式解决方案，都依托于重型级的应用服务器，这是不适合于微服务架构的。

 

补偿事务（TCC）方案

TCC 其实就是采用的补偿机制，其核心思想是：针对每个操作，都要注册一个与其对应的确认和补偿（撤销）操作。TCC模型是把锁的粒度完全交给业务处理。它分为三个阶段：

1. Try 阶段主要是对业务系统做检测及资源预留
2. Confirm 阶段主要是对业务系统做确认提交，Try阶段执行成功并开始执行 Confirm阶段时，默认 Confirm阶段是不会出错的。即：只要Try成功，Confirm一定成功。
3. Cancel 阶段主要是在业务执行错误，需要回滚的状态下执行的业务取消，预留资源释放。

 

下面对TCC模式下，A账户往B账户汇款100元为例子，对业务的改造进行详细的分析：

 

汇款服务和收款服务分别需要实现，Try-Confirm-Cancel接口，并在业务初始化阶段将其注入到TCC事务管理器中。

[汇款服务]
Try：
   检查A账户有效性，即查看A账户的状态是否为“转帐中”或者“冻结”；
   检查A账户余额是否充足；
   从A账户中扣减100元，并将状态置为“转账中”；
   预留扣减资源，将从A往B账户转账100元这个事件存入消息或者日志中；
Confirm：
 不做任何操作；
Cancel：
   A账户增加100元；
 从日志或者消息中，释放扣减资源。

[收款服务]
Try：
 检查B账户账户是否有效；
Confirm：
   读取日志或者消息，B账户增加100元；
   从日志或者消息中，释放扣减资源；
Cancel：
 不做任何操作。

由此可以看出，TCC模型对业务的侵入强，改造的难度大。简单的来说，就是把保证数据一致性的事情放到了业务代码里进行处理。

 

本地消息表（异步确保）

本地消息表这种实现方式应该是业界使用最多的，其核心思想是将分布式事务拆分成本地事务进行处理，这种思路是来源于ebay。我们可以从下面的流程图中看出其中的一些细节：

 

基本思路就是：

 

消息生产方，需要额外建一个消息表，并记录消息发送状态。消息表和业务数据要在一个事务里提交，也就是说他们要在一个数据库里面。然后消息会经过MQ发送到消息的消费方。如果消息发送失败，会进行重试发送。

 

消息消费方，需要处理这个消息，并完成自己的业务逻辑。此时如果本地事务处理成功，表明已经处理成功了，如果处理失败，那么就会重试执行。如果是业务上面的失败，可以给生产方发送一个业务补偿消息，通知生产方进行回滚等操作。

 

生产方和消费方定时扫描本地消息表，把还没处理完成的消息或者失败的消息再发送一遍。如果有靠谱的自动对账补账逻辑，这种方案还是非常实用的。

 

举个例子A用100元去买一瓶水。

1.当你扣钱的时候，你需要在你扣钱的服务器上新增加一个本地消息表，你需要把你扣钱和写入减去水的库存到本地消息表放入同一个事务(依靠数据库本地事务保证一致性)。

2.这个时候有个定时任务去轮询这个本地事务表，把没有发送的消息，扔给商品库存服务器，叫他减去水的库存，到达商品服务器之后这个时候得先写入这个服务器的事务表，然后进行扣减，扣减成功后，更新事务表中的状态。

3.商品服务器通过定时任务扫描消息表或者直接通知扣钱服务器，扣钱服务器本地消息表进行状态更新。

4.针对一些异常情况，定时扫描未成功处理的消息，进行重新发送，在商品服务器接到消息之后，首先判断是否是重复的，如果已经接收，在判断是否执行，如果执行在马上又进行通知事务，如果未执行，需要重新执行需要由业务保证幂等，也就是不会多扣一瓶水。

本地消息队列是BASE理论，是最终一致模型，适用于对一致性要求不高的。实现这个模型时需要注意重试的幂等。

 

MQ事务消息

事务消息作为一种异步确保型事务， 将两个事务分支通过MQ进行异步解耦，事务消息的设计流程同样借鉴了两阶段提交理论，整体交互流程如下图所示：

1. 事务发起方首先发送 prepare 消息到 MQ。
2. 在发送 prepare 消息成功后执行本地事务。
3. 根据本地事务执行结果返回 commit 或者是 rollback。
4. 如果消息是 rollback，MQ 将删除该 prepare 消息不进行下发，如果是 commit 消息，MQ 将会把这个消息发送给 consumer 端。
5. 如果执行本地事务过程中，执行端挂掉，或者超时，MQ 将会不停的询问其同组的其它 producer 来获取状态。
6. Consumer 端的消费成功机制有 MQ 保证。

 

关于MQ事务消息的讲解可以去看一下—RocketMQ 4.3 正式发布，支持分布式事务

 

Saga事务

Saga是30年前一篇数据库伦理提到的一个概念。其核心思想是将长事务拆分为多个本地短事务，由Saga事务协调器协调，如果正常结束那就正常完成，如果某个步骤失败，则根据相反顺序一次调用补偿操作。 Saga的组成：

每个Saga由一系列sub-transaction Ti 组成 每个Ti 都有对应的补偿动作Ci，补偿动作用于撤销Ti造成的结果,这里的每个T，都是一个本地事务。 可以看到，和TCC相比，Saga没有“预留 try”动作，它的Ti就是直接提交到库。

 

Saga的执行顺序有两种：

T1, T2, T3, ..., Tn

T1, T2, ..., Tj, Cj,..., C2, C1，其中0 < j < n Saga定义了两种恢复策略：

 

向后恢复，即上面提到的第二种执行顺序，其中j是发生错误的sub-transaction，这种做法的效果是撤销掉之前所有成功的sub-transation，使得整个Saga的执行结果撤销。 向前恢复，适用于必须要成功的场景，执行顺序是类似于这样的：T1, T2, ..., Tj(失败), Tj(重试),..., Tn，其中j是发生错误的sub-transaction。该情况下不需要Ci。

这里要注意的是，在saga模式中不能保证隔离性，因为没有锁住资源，其他事务依然可以覆盖或者影响当前事务。

 

拿100元买一瓶水的例子来说，这里定义

T1=扣100元 T2=给用户加一瓶水 T3=减库存一瓶水

C1=加100元 C2=给用户减一瓶水 C3=给库存加一瓶水

我们一次进行T1,T2，T3如果发生问题，就执行发生问题的C操作的反向。 上面说到的隔离性的问题会出现在，如果执行到T3这个时候需要执行回滚，但是这个用户已经把水喝了(另外一个事务)，回滚的时候就会发现，无法给用户减一瓶水了。这就是事务之间没有隔离性的问题

可以看见saga模式没有隔离性的影响还是较大，可以参照华为的解决方案:从业务层面入手加入一 Session 以及锁的机制来保证能够串行化操作资源。也可以在业务层面通过预先冻结资金的方式隔离这部分资源， 最后在业务操作的过程中可以通过及时读取当前状态的方式获取到最新的更新。

 

最后

还是那句话，能不用分布式事务就不用，如果非得使用的话，结合自己的业务分析，看看自己的业务比较适合哪一种，是在乎强一致，还是最终一致即可。上面对解决方案只是一些简单介绍，如果真正的想要落地，其实每种方案需要思考的地方都非常多，复杂度都比较大，所以最后再次提醒一定要判断好是否使用分布式事务。

 

 

 

参考文章

分布式事务不理解？一次给你讲清楚！

再有人问你分布式事务，把这篇扔给他

分布式系统架构常识：CAP理论