概述
在分布式系统的环境下，单机的事务控制已经无法满足多种服务环环相扣的事务控制。市面上有许多实现分布式事务的方案，下文会一一列举。
分布式事务在分布式环境下，为了满足可用性、性能与降级服务的需要，降低一致性与隔离性的要求，一方面遵循 BASE 理论：
- 基本业务可用性（Basic Availability）
- 柔性状态（Soft state）
- 最终一致性（Eventual consistency）
同样的，分布式事务也部分遵循 ACID 规范：
- 原子性：严格遵循
- 一致性：事务完成后的一致性严格遵循；事务中的一致性可适当放宽
- 隔离性：并行事务间不可影响；事务中间结果可见性允许安全放宽
-
两阶段提交/XA
XA是由X/Open组织提出的分布式事务的规范，XA规范主要定义了（全局）事务管理器（TM）和（局部）资源管理器（RM）之间的接口。本地的数据库如MySQL在XA中扮演的是RM角色。
XA一共分为两阶段： 第一阶段（prepare）：即所有的参与者RM准备执行事务并锁住需要的资源。参与者ready时，向TM报告已准备就绪。
- 第二阶段（commit/rollback）：当事务管理者(TM)确认所有参与者(RM)都ready后，向所有参与者发送commit命令。
目前主流的数据库基本都支持XA事务，包括MySQL、Oracle、SQL Server、PostgreSQL。
XA事务由一个或多个资源管理器（RM）、一个事务管理器（TM）和一个应用程序（ApplicationProgram）组成。
如果有任何一个参与者prepare失败，那么TM会通知所有完成prepare的参与者进行回滚。
一个成功完成的XA事务时序图如下：
注意的是，如果有任何一个参与者prepare失败，那么TM会通知所有完成prepare的参与者进行回滚。
SAGA
Saga是这一篇数据库论文Saga提到的一个方案。其核心思想是将长事务拆分为多个本地短事务，由Saga事务协调器协调，如果正常结束那就正常完成，如果某个步骤失败，则根据相反顺序一次调用补偿操作。
把上面的转账作为例子，一个成功完成的Saga事务时序图如下：
Saga事务的特点：
- 并发度高，不用像XA事务那样长期锁定资源
- 需要定义正常操作以及补偿操作，开发量比XA大
- 一致性较弱，对于转账，可能发生A用户已扣款，最后转账又失败的情况
论文里面的Saga内容较多，包括两种恢复策略，包括分支事务并发执行，我们这里的讨论，仅包括最简单的Saga。
Saga适用的场景较多，长事务适用，对中间结果不敏感的业务场景适用。
如果想要进一步研究Saga，Go语言可参考DTM，Java语言可参考seata。
TCC
关于 TCC（Try-Confirm-Cancel）的概念，最早是由 Pat Helland 于 2007 年发表的一篇名为《Life beyond Distributed Transactions:an Apostate’s Opinion》的论文提出。
TCC分为3个阶段：
- Try 阶段：尝试执行，完成所有业务检查（一致性）, 预留必须业务资源（准隔离性）
- Confirm 阶段：确认执行真正执行业务，不作任何业务检查，只使用 Try 阶段预留的业务资源，Confirm 操作要求具备幂等设计，Confirm 失败后需要进行重试。
- Cancel 阶段：取消执行，释放 Try 阶段预留的业务资源。Cancel 阶段的异常和 Confirm 阶段异常处理方案基本上一致，要求满足幂等设计。
把上面的转账作为例子，通常会在Try里面冻结金额，但不扣款，Confirm里面扣款，Cancel里面解冻金额，一个成功完成的TCC事务时序图如下：
TCC特点如下：
- 并发度较高，无长期资源锁定。
- 开发量较大，需要提供Try/Confirm/Cancel接口。
- 一致性较好，不会发生SAGA已扣款最后又转账失败的情况
- TCC适用于订单类业务，对中间状态有约束的业务
如果想要进一步研究TCC，go语言可参考DTM，java语言可参考seata。
本地消息表
本地消息表这个方案最初是 ebay 架构师 Dan Pritchett 在 2008 年发表给 ACM 的文章。设计核心是将需要分布式处理的任务通过消息的方式来异步确保执行。
大致流程如下：
写本地消息和业务操作放在一个事务里，保证了业务和发消息的原子性，要么他们全都成功，要么全都失败。
容错机制：
- 扣减余额事务 失败时，事务直接回滚，无后续步骤
- 轮序生产消息失败， 增加余额事务失败都会进行重试
本地消息表的特点：
- 长事务仅需要分拆成多个任务，使用简单
- 生产者需要额外的创建消息表
- 每个本地消息表都需要进行轮询
- 消费者的逻辑如果无法通过重试成功，那么还需要更多的机制，来回滚操作
适用于可异步执行的业务，且后续操作无需回滚的业务。
事务消息
在上述的本地消息表方案中，生产者需要额外创建消息表，还需要对本地消息表进行轮询，业务负担较重。阿里开源的RocketMQ 4.3之后的版本正式支持事务消息，该事务消息本质上是把本地消息表放到RocketMQ上，解决生产端的消息发送与本地事务执行的原子性问题。
事务消息发送及提交：
- 发送消息（half消息）
- 服务端存储消息，并响应消息的写入结果
- 根据发送结果执行本地事务（如果写入失败，此时half消息对业务不可见，本地逻辑不执行）
- 根据本地事务状态执行Commit或者Rollback（Commit操作发布消息，消息对消费者可见）
正常发送的流程图如下：
补偿流程：
- 对没有Commit/Rollback的事务消息（pending状态的消息），从服务端发起一次“回查”
- Producer收到回查消息，返回消息对应的本地事务的状态，为Commit或者Rollback
- 事务消息方案与本地消息表机制非常类似，区别主要在于原先相关的本地表操作替换成了一个反查接口
事务消息特点如下：
- 长事务仅需要分拆成多个任务，并提供一个反查接口，使用简单
- 消费者的逻辑如果无法通过重试成功，那么还需要更多的机制，来回滚操作
适用于可异步执行的业务，且后续操作无需回滚的业务。
最大努力通知
发起通知方通过一定的机制最大努力将业务处理结果通知到接收方。具体包括：
- 有一定的消息重复通知机制。因为接收通知方可能没有接收到通知，此时要有一定的机制对消息重复通知。
- 消息校对机制。如果尽最大努力也没有通知到接收方，或者接收方消费消息后要再次消费，此时可由接收方主动向通知方查询消息信息来满足需求。
前面介绍的的本地消息表和事务消息都属于可靠消息，与这里介绍的最大努力通知有什么不同？
可靠消息一致性，发起通知方需要保证将消息发出去，并且将消息发到接收通知方，消息的可靠性关键由发起通知方来保证。
最大努力通知，发起通知方尽最大的努力将业务处理结果通知为接收通知方，但是可能消息接收不到，此时需要接收通知方主动调用发起通知方的接口查询业务处理结果，通知的可靠性关键在接收通知方。
解决方案上，最大努力通知需要：
- 提供接口，让接受通知放能够通过接口查询业务处理结果
- 消息队列ACK机制，消息队列按照间隔1min、5min、10min、30min、1h、2h、5h、10h的方式，逐步拉大通知间隔 ，直到达到通知要求的时间窗口上限。之后不再通知
最大努力通知适用于业务通知类型，例如微信交易的结果，就是通过最大努力通知方式通知各个商户，既有回调通知，也有交易查询接口。
AT事务模式
这是阿里开源项目seata中的一种事务模式，在蚂蚁金服也被称为FMT。优点是该事务模式使用方式，类似XA模式，业务无需编写各类补偿操作，回滚由框架自动完成，缺点也类似AT，存在较长时间的锁，不满足高并发的场景。有兴趣的同学可以参考seata-AT。
异常处理
在分布式事务的各个环节都有可能出现网络以及业务故障等问题，这些问题需要分布式事务的业务方做到防空回滚，幂等，防悬挂三个特性。
异常情况
下面以TCC事务说明这些异常情况：
空回滚：
在没有调用TCC资源Try方法的情况下，调用了二阶段的Cancel方法，Cancel方法需要识别出这是一个空回滚，然后直接返回成功。
出现原因是当一个分支事务所在服务宕机或网络异常，分支事务调用记录为失败，这个时候其实是没有执行Try阶段，当故障恢复后，分布式事务进行回滚则会调用二阶段的Cancel方法，从而形成空回滚。
幂等：
由于任何一个请求都可能出现网络异常，出现重复请求，所以所有的分布式事务分支，都需要保证幂等性
悬挂：
悬挂就是对于一个分布式事务，其二阶段Cancel接口比Try接口先执行。
出现原因是在 RPC 调用分支事务try时，先注册分支事务，再执行RPC调用，如果此时 RPC 调用的网络发生拥堵，RPC超时以后，TM就会通知RM回滚该分布式事务，可能回滚完成后，RPC请求才到达参与者真正执行。
下面看一个网络异常的时序图，更好的理解上述几种问题 。
- 业务处理请求4的时候，Cancel在Try之前执行，需要处理空回滚
- 业务处理请求6的时候，Cancel重复执行，需要幂等
- 业务处理请求8的时候，Try在Cancel后执行，需要处理悬挂
面对上述复杂的网络异常情况，目前看到各家建议的方案都是业务方通过唯一键，去查询相关联的操作是否已完成，如果已完成则直接返回成功。相关的判断逻辑较复杂，易出错，业务负担重。
总结
本文介绍了分布式事务的一些基础理论，并对常用的分布式事务方案进行了讲解，在文章的后半部分还给出了事务异常的原因、分类以及优雅的解决方案。
若有收获，就点个赞吧
0 人点赞
