阿里妹导读：分布式事务中涉及的参与者分布在异步网络中，参与者通过网络通信来达到分布式一致性，网络通信不可避免出现失败、超时的情况，因此分布式事务的实现比本地事务面临更多的困难。本文归纳总结五种分布式事务解决方案，并剖析其特点。较长，同学们可收藏后再看。
文末福利：Java程序员学习清单。
事务是一组不可分组的操作集合，这些操作要么都成功执行，要么都取消执行。最典型的需要事务的场景是银行账户间的转账：假如A账户要给B账户转账元，那么A账户要扣减元，B账户要增加元，这两个账户的数据变更都成功才可算作转账成功。更严格来说，可以用ACID四个特性表述事务：
Atomicity：原子性，事务中的所有操作要么都成功执行，要么都取消执行，不能存在部分执行，部分不执行的状态。
Consistency：一致性，举个例子简单的理解就是，A、B两个账户各有元，无论两个账户并发相互转账多少次，两个账户的资金总额依然是元。
Isolation：隔离性，并发事务之间的相互影响程度，隔离性也是分级别的：读未提交、读已提交、可重复读等。
Durability：持久性，事务完成后对数据的更改不会丢失。
单体数据库不涉及网络交互，所以在多表之间实现事务是比较简单的，这种事务我们称之为本地事务。
但是单体数据库的性能达到瓶颈的时候，就需要分库(分物理实例)，就会出现跨库(数据库实例)的事务需求；随着企业应用的规模越来越大，企业会进一步进行服务化改造，以满足业务增长的需求；当前微服务架构越来越流行，跨服务的事务场景也会越来越多。
这些都是分布式事务的需求。分布式事务是指是指事务的发起者、参与者、数据资源服务器以及事务管理器分别位于分布式系统的不同节点之上。
概括起来，分布式事务有三种场景：
跨数据库分布式事务跨服务分布式事务混合式分布式事务
分布式事务中涉及的参与者分布在异步网络中，参与者通过网络通信来达到分布式一致性，网络通信不可避免出现失败、超时的情况，因此分布式事务的实现比本地事务面临更多的困难。下面介绍几种常见的分布式事务解决方案。
分布式事务模式
XASpecification
最早的分布式事务产品可能是ATT在20世纪80年代推出的Tuxedo(TransactionsforUnix,ExtendedforDistributedOperations)，Tuxedo最早是为了电信领域的OLTP系统研发的分布式事务中间件，后来标准化组织X/Open吸收采纳了Tuxedo的设计思想和一些接口，推出了分布式事务规范：XASpecification。
XA规范中定义了分布式事务处理模型，这个模型中包含四个核心角色：
RM(ResourceManagers)：资源管理器，提供数据资源的操作、管理接口，保证数据的一致性和完整性。最有代表性的就是数据库管理系统，当然有的文件系统、MQ系统也可以看作RM。
TM(TransactionManagers)：事务管理器，是一个协调者的角色，协调跨库事务关联的所有RM的行为。
AP(ApplicationProgram)：应用程序，按照业务规则调用RM接口来完成对业务模型数据的变更，当数据的变更涉及多个RM且要保证事务时，AP就会通过TM来定义事务的边界，TM负责协调参与事务的各个RM一同完成一个全局事务。
CRMs(CommunicationResourceManagers)：主要用来进行跨服务的事务的传播。
下图是XA规范中定义的事务模型图，其中：发起分布式事务的TM实例称之为root节点，其他的TM实例可以统称为事务的参与者。事务发起者负责开启整个全局事务，事务参与者各自负责执行自己的事务分支。如果TM实例发起了对其他TM实例的服务调用，那么发起者就被成为Superior，被调用这就被称之为Subordinate节点。
图源：《DistributedTransactionProcessing:ReferenceModel,Version3》Page32,Figure3-2
XA规范中分布式事务是构建在RM本地事务（此时本地事务被看作分支事务）的基础上的，TM负责协调这些分支事务要么都成功提交、要么都回滚。XA规范把分布式事务处理过程划分为两个阶段，所以又叫两阶段提交协议（twophrase