分布式事务是指会涉及到操作多个数据库的事务，其实就是将对同一库事务的概念扩大到了对多个库的事务。目的是为了保证分布式系统中的数据一致性。分布式事务处理的关键是必须有一种方法可以知道事务在任何地方所做的所有动作，提交或回滚事物的决定必须产生统一的结果(全部提交或全部回滚)
XA规范
X/Open组织定义了分布式事务处理模型。X/Open DTP模型包括应用程序(AP),事务管理(TM),资源管理器(RM),通信资源管理器(CRM)四部分。一般厂家的事务管理器(TM)是交易中间件，厂家的资源管理器(RM)是数据库，常见的通信资源管理器(CRM)是消息中间件。通常把一个数据库内部的事务处理，如对多个表的操作，作为本地事务看待。数据库的事务处理对象时本地事务而分布式事务处理的对象时全局事务，所谓全局事务，是指分布式事务处理环境中，多个数据库可能要共同完成同一个工作，这个工作即是全局事务，在一个DTP环境中，交易中间件是必需的，由它通知和协调相关数据库的提交或回滚，而一个数据库只将其自己所做的操作映射到全局事务中。
XA就是X/Open DTP定义的交易中间件与数据库之间的接口规范，交易中间件用它来通知数据库事务的开始，结束以及提交，回滚等。XA接口函数由数据库厂商提供。
二阶段提交协议和三阶段提交协议就是根据这一思想衍生出来的。可以说二阶段提交是实现XA分布式协议的关键(两阶段提交主要保证了分布式事务的原子性：即所有节点要么全做要么全不做)
2PC
二阶段提交(Two-phaseCommit)是指，为了使基于分布式架构下的所有节点在进行事务提交时保持一致性而设计的一种算法。二阶段提交也被称为一种协议，二阶段的算法思路可以概括为：参与者将操作成败通知协调者，再由协调者根据所有参与者的反馈情报决定各参与者是否要提交操作还是中止操作。
所谓两阶段是指:第一阶段：准备阶段(投票阶段)和第二阶段:提交阶段(执行阶段)
准备阶段
事务协调者(事务管理器)给每个参与者(资源管理器)发送prepare消息，每个参与者要么直接返回失败，要么在本地执行事务，写本地的redo和undo日志，但未提交，到达一种"万事俱备只欠东风"的状态。
1.协调者节点向所有参与者节点询问是否可以执行提交操作(vote)，并等待各参与者节点的响应
2.参与者节点执行询问发起为止的所有事务操作，并将undo和redo信息写入日志(若成功其实每个参与者已经执行了事务操作)
3.各参与者节点响应协调者节点发起的询问，如果参与者节点的事务操作实际执行成功，则它返回一个"同意"消息；如果参与者节点的事务操作实际执行失败，则它返回一个"中止"消息。
提交阶段
如果协调者收到了参与者的失败消息或者超时，直接给每个参与者发送回滚(Rollback)消息；否则，发送提交(Commit)消息；参与者根据协调者的指令执行提交或回滚操作，释放所有事务处理过程中使用的锁资源(必须在最后阶段释放锁资源)
当协调者节点从所有参与者节点获得相应消息都为“同意”时：
1.协调者节点向所有参与者节点发出正式提交的请求
2.参与者节点正式完成操作，并释放在整个事务期间内占用的资源。
3.参与者节点向协调者节点发送“完成”消息
4.协调者节点受到所有参与者节点反馈的“完成”消息后，完成事务。
不管最后结果如何，第二阶段都会结束当前事务。
回滚操作亦是如此
而极端提交有几个缺点：
1.同步阻塞问题
在执行过程中，所有参与节点都是事务阻塞型的，当参与者占用公共资源时，其他第三方节点访问公共资源不得不处于阻塞状态。
2.单点故障
由于协调者的重要性，一旦协调者发送故障，参与者会一直阻塞下去。尤其在第二阶段，协调者发送故障，那么所有参与者还都处于锁定事务资源的专题，而无法继续完成事务操作。
3.数据不一致
当协调者发向参与者发送commit请求之后，发生了局部网络异常或者在发送commit请求后协调者发生了故障，这会导致只有一部分参与者接受到了commit请求。而在这部分参与者接到commit之后会执行commit操作，但其他部分为收到commit的机器则服务执行事务提交。于是整个分布式系统便出现数据不一致的现象
4.二阶段无法解决的问题：协调者再发出commit消息后宕机，而唯一接收到这条消息的参与者同时也宕机了。那么即使协调者通过选举产生了新的协调者，这条事务的状态也是不确定的，没人知道事务是否已经提交。
3PC
三阶段提交(Three-phase commit)是二阶段提交的改进版本
与二阶段提交的不同是，三阶段提交有两个改动点。
1.引入超时机制同时在协调者和参与者中都引入超时机制
2.在第一个阶段和第二阶段中插入一个准备阶段，保证了在最后提交阶段之前各参与节点的状态一致的。
除了引入超时机制之外,3PC把2PC的准备阶段再次一份为二，这样三阶段提交就有CanCommit,PreCommit,DoCommit三个阶段。
CanCommit阶段
3pc的cancommit阶段与2pc的准备阶段很像，协调者向参与者发送commit请求，参与者如果可以提交就返回yes响应，否则返回no响应
PreCommit阶段
协调者根据参与者的反映情况来决定是否可以继续事务的PreCommit操作。
1.假如协调者从所有参与者获得反馈都是yes响应，那么就会执行事务的预执行（发送预提交请求：协调者向参与者发送PreCommit请求，并进入Prepared阶段；事务预提交：参与者接收到PreCommit请求后，会执行事务操作，并将undo和redo信息记录到事务日志中；响应反馈：如果参与者成功的执行了事务操作，则返回ACK响应，同时开始等待最终指令）
2.假如任何一个参与者向协调者发送了no响应，或者等待超时后，协调者没有收到参与者的响应，那么久执行事务的中断。（发送中断：协调者向所有参与者发送abort请求；中断事务：参与者接收到来自协调者的abort请求后(或超时之后，仍未收到协调者的请求)执行事务的中断）
DoCommit阶段
该阶段进行真正的事务提交。可以分为两种情况
执行提交：1.发送提交请求，协调者收到参与者发送ACK响应，那么他将从预提交状态进入提交状态，并向所有参与者发送doCommit请求；2.事务提交，参与者收到doCommit请求后，执行正式的事务提交，并在完成事务提交之后释放所有事务资源；3.响应反馈，事务提交完成后，向协调者发送Ack响应；4.完成事务，协调者接收到所有参与者的ack响应后，完成事务。
中断事务：协调者没有接收到参与者发送的ACK响应（可能是接受者发送的不是ACK响应，也可能是响应超时），那么就会执行中断事务；1.发送中断请求，协调者向所有参与者发送abort请求；2.事务回滚，参与者接收到abort请求后，利用其在阶段二记录的undo信息来执行事务的回滚操作，并在完成回滚之后释放所有的事务资源；3.反馈结果，参与者完成是服务回滚后，向协调者发送ACK消息；4.中断事务，协调者接收到参与者反馈的ACK消息后，执行事务的中断。
在doCommit阶段，如果参与者无法及时收到来自协调者的doCommit或者abort请求，会在等待超时之后，会继续进行事务的提交。
2pc与3pc的区别
相对于2pc，3pc主要解决的单点故障问题，并减少阻塞，因为一旦参与者无法及时收到来自协调者的信息之后，它会默认执行commit，而不会一直持有事务资源并处于阻塞状态。但是这种机制也会导致数据一致性问题，因为由于网络原因，协调者发送的abort响应没有及时被参与者接收到，那么参与者在等待超时之后执行了commit操作。这样就和其他接到abort命令并执行回滚的参与者之间存在数据不一致的情况。
柔性事务
TCC是分布式系统场景下的一种事务解决方案，他和传统的分布式事务的最大区别是分布式事务会锁资源，而tcc属于柔性事务不会锁资源。
实现柔性事务三种方式，tcc,消息机制，补偿型。
TCC即Try-Confirm-Cancel
try:资源预留&锁定，事务发起方将调用服务提供方的Try方法来锁定业务所需要的所有资源。
Confirm:确认执行业务逻辑操作，这里使用的资源一定都是在try中预留的资源，try+confirm组合起来是一次完整的业务逻辑。
Cancel：取消执行业务逻辑，这里和普通的补偿性事务不同，因为try阶段只是预留资源，并未真正执行操作，因此取消操作只需要释放try阶段预留的资源，而不需要执行数据库操作来补偿。
用户通过编码实现tcc并发布成服务，这个tcc服务就可以作为资源参与到分布式事务中；事务管理器分2阶段协调所有的TCC资源，使得所有TCC资源状态最终都是一致，要么全部提交，要么全部回滚；TCC自编码的特性决定TCC资源管理器可以跨DB、跨应用实现资源管理，将对不同的DB访问、不同的业务操作通过编码方式转换一个原子操作，解决了复杂业务场景下的事务问题；同时TCC的每一个操作对于DB来讲都是一个本地DB事务，操作结束则本地DB事务结束，数据库的资源也就被释放；这就规避了数据库层面的2PC对资源占用导致的性能低下问题。
TCC与2PC协议比较
TCC位于业务服务层而非资源层
TCC没有单独的准备(Prepare)阶段,Try操作兼备资源操作与准备能力 Try操作可以灵活选择业务资源的锁定粒度(以业务定粒度)
TCC有较高开发成本
异步确保
2PC的处理过程中一个很大的问题是，存在大量的同步等待，这便意味着操作之间的强耦合，一旦发生了失败或是超时，造成的影响往往是灾难性的。但是分布式情况下，超时和失败又是很可能出现的情况，所以2PC手段没法保证系统的可用性。
那么怎么优化呢？可以将操作解耦，使用消息队列（或者某种可靠的通信机制）来连接不同的实例上的操作。这样的通信机制使操作异步化，于是我们还需要一个能够确保消息执行成功的确保机制，以上两点的综合就是现在最常用的柔性事务解决方案，我们暂且叫它“异步确保”（因为这种方案并非有一个统一的叫法），核心思路其实就是：用消息队列保证最终一致性。
重试与幂等
在接下来讲到的各种思路中，我们都无法避免一个问题，那就是接口调用或者说操作的失败，分布式情况下系统的状态往往不如单机条件下确定，所以可能经常需要重试，而不是一失败就回滚。
幂等性，其实是一个数学概念。幂等函数，或幂等方法，是指可以使用相同参数重复执行，并能获得相同结果的函数，如：f(f(x)) = f(x)
在编程中一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同。也就是说，同一个方法，使用同样的参数，调用多次产生的业务结果与调用一次产生的业务结果相同。这一个要求其实也比较好理解，因为要保证数据的最终一致性，很多解决方法都会有很多重试的操作，如果一个方法不保证幂等，那么将无法被重试。幂等操作的实现方式有多种，如在系统中缓存所有的请求与处理结果、检测到重复操作后，直接返回上一次的处理结果等。
可补偿操作
提到事务，为了保证原子性，就可能发生commit和rollback，那么在分布式事务中，要想进行rollback，就需要提供可补偿操作。比如上面的订单处理的例子中，在调用积分服务给积分帐户增加积分操作执行之后，经过分布式事务协调，最终决定回滚整个事务，那么就需要提供一个调用积分服务给积分帐户扣减积分的操作。并且，补偿操作同时也需要满足幂等性。
记录日志+补偿。记录事务的开始和结束状态。事务根据日志记录找回事务的当前执行状态，并根据状态决定重试异常步骤，也就是正向补偿，或者回滚上一次执行步骤，也就是反向补偿。
