本文主要是讲述分布式事务的理论及常用的技术方案，主要源自各类学习和工作总结，如有不妥之处，还望指正。分布式事务的其他基础请自行查阅资料。
一、分布式事务产生的原因
分布式事务的产生，源自互联网、电商等的发展，当同一个系统不同模块不同业务的数据在一个存储设备里，随着业务的发展，系统逐渐满足不了业务的发展时，常用的手段就是“拆”，拆的手段有垂直拆分和水平拆分，针对业务模块和数据库存储，都可以进行垂直拆分和水平拆分。拆分后就会存在不同的业务使用自己的数据库进行存储，这就会导致一个操作需要进行跨数据库操作。这就是分布式事务产生的最基本的原因所在。而我们知道，只要是事务，必须要满足事务的四性（ACID），为了使事务的四性得到满足，业内使用了多种技术手段，但各种技术手段都有其优点和缺点。
事务的四性（ACID）：Automicity（原子性）、Consistency（一致性）、Isolation（隔离性）、Durability（持久性）。
比如：电商的下单，里面包含写订单表、扣减商品库存、写财务结算，订单信息、商品库存、财务模块按业务已经拆分到不同的模块，各自有属于自己的数据库，这个时候就是一个典型的分布式事务场景。
二、理论基础
此处主要说2个理论基础，一个是分布式的CAP定理，一个是BASE理论。
CAP：指的是在一个分布式系统中，一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）这三个要素最多只能同时实现两点，不可能三者兼顾。在分布式场景中，由于网络硬件等客观因素，网络之间的通信可能会存在中断、丢包等情况，所以分区容错性（Partition tolerance）是我们分布式场景中必须要满足的，三要素中就只能有有这2种组合：CP和AP。
AP：AP模型强调的是系统的可用性，在做系统设计时，需要优先考虑可用性；
CP：CP模型强调的是系统的一致性，在做系统设计时，需要优先考虑一致性；
基于CAP定理的AP模型和CP模型，又演化出了BASE理论。BASE是Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）的简写。核心是既然没办法做到强一致性，但每一个应用都可根据自身的业务特点采用适当的方式来达到最终一致性。
Basically Available（基本可用）：指系统出现不可预知的故障时，允许损失部分可用性，但这绝不等价于不可用。比如：系统某功能的正常响应时间是0.1秒，但由于系统出现异常（机房断电、光纤挖断等）系统功能的响应时间升到1-2秒；再比如电商的大促或秒杀，为了保证系统的稳定性，当用户流量超过了系统阈值，可把部分用户引流到一个降级页面。
Soft state（软状态）：与硬状态相对。系统中的数据存在中间状态，并认为该中间状态不影响系统的整体可用性，即表示数据副本之间的同步有延迟。
Eventually consistent（最终一致性）：系统中的所有数据副本，在经过一段时间后，所有数据的状态都能达到一个最终的一致的状态。
三、刚性分布式事务
刚性分布式事务的特点是：数据的状态强调的是强一致性，系统能支持的并发低，事务执行的时间都比较短，属于短事务，所有数据在事务内同步执行。刚性分布式事务遵循XA协议，通过实现XA的接口来实现分布式事务。XA规范由AP（Application Program）、RM（Resource Manager）、TM（Transaction Manager）组成。
AP：定义事务的开始和结束，并访问事务内的资源；
RM：通常指的就是数据库资源；
TM：负责管理事务，分配事务的唯一标识、监控事务的执行情况、并负责事务的提交、回滚等操作；
下面列出一些常见的实现XA协议的分布式事务方法。
两阶段提交（2PC）：
也是XA的标准实现，分为准备阶段和提交阶段，时序图如下：
AP向TM发起commit请求，TM向RM发送prepare，当TM收到所有的RM返回的ok消息后，TM再向所有的RM发送commit指令，待收到所有的RM返回的ok消息后，commit才算完成。在prepare阶段，当有一个RM返回失败的时候，则不能进行第二步的commit操作，TM释放所有占用的资源；在commit阶段，当有一个RM返回失败时，则TM都要协调commit进行补偿，保证所有提交到RM的commit请求，要么都成功、要么都失败。
2PC的缺点：
1、同步阻塞：所有参与事务的资源都处于阻塞状态；
2、TM瓶颈：当TM故障时，所有的参与者都将被锁定，资源得不到释放；
3、RM资源锁定时间过长；
4、全局锁定（隔离级别串行化），不适合长事务，并发低；
基于2PC的缺点，又提出三阶段（3PC）提交。
三阶段（3PC）提交：
三阶段（3PC）提交分为CanCommit、PreCommit和DoCommit三个阶段，时序图如下：
CanCommit：TM向所有RM发出CanCommit指令，RM收到指令后，判断可否提交事务，如果可以返回ok，否则返回no；
PreCommit：当TM收到所有RM都返回CanCommit的结果为ok时，TM向所有RM发出PreCommit；当有一个RM返回no或超时，导致TM没收到反馈则事务中断，TM向所有RM发出abort终止事务，TM收到abort后终止事务，释放资源。如果RM没收到TM发出的abort或是超时，则RM也会中断自身的事务，释放资源；
DoCommit：TM收到所有RM都返回PreCommit的结果为ok时，TM向所有RM发出DoCommit，执行事务真正的提交，TM收到所有RM的DoCommit的执行结果为ok时，释放所占用的所有资源；当有一个RM返回no或超时，导致TM没收到反馈则事务中断，TM向所有RM发出abort终止事务，各个RM收到abort后利用CanCommit阶段的Undo信息执行回滚操作，释放占用的资源；但是，如果RM没收到TM发出的abort或是超时后，则RM会继续提交事务，这将导致数据的不一致。
三阶段相比两阶段，优点有：降低阻塞范围；TM瓶颈问题得到部分解决，即在第一二阶段时，当超时的时候RM会自动释放资源，不依赖TM。但进入第三阶段后，如果超时则不会释放资源，而会继续提交事务，这种情况下，将导致数据的不一致。
四、柔性分布式事务
柔性分布式事务是相对刚性分布式事务、是对强一致性的妥协，从而降低对数据库资源的锁定时间，提升系统的性能。柔性分布式事务适合于长事务、高并发，强调最终一致性的场合。常用的实现柔性分布式事务的方式有：TCC模型、Saga模型、基于消息队列的异步模型。
1、TCC（Try-Confirm-Cancel）模型
TCC是一个两阶段提交（2PC）的实现，每一个业务都需要实现Try-Confirm-Cancel三个接口，Try是尝试执行业务，完成所有业务执行前的检查；Confirm是真正执行业务，提交事务，释放资源；Cancel是业务失败的时候回滚业务操作，释放资源。
A账户向B账户转账100元为例，TCC执行步骤如下：
TCC模型的实现是分为2步操作完成一次事务操作，达到最终事务的一致性。
2、Saga模型
起源于1987年Hector Garcia-Molina和Kenneth Salem发表的论文《Sagas》,主要思想是把一个分布式事务拆分为多个本地事务，每一个本地事务都有相应的正常执行方法和异常补偿方法，当任意一个本地事务出错时，都可以通过调用相应的异常补偿方法恢复之前的事务或是继续执行未完成的事务，保证事务的最终一致性。
Saga事务由一系列的sub-transaction Tn及对应的补偿事务Cn组成。
在事务执行过程中，当有任何一个子事务Tj执行失败时，将触发事务补偿，事务的补偿有两种方式。一种是向后补偿，一种是向前补偿。向后补偿指子事务Tj失败后，将把已经执行的子事务Tj-1,Tj-2，……T2，T1的子事务通过执行各自对应的补偿事务Cj-1,Cj-2,……C2，C1（0
