完成事务：协调者接收到所有参与者反馈的 Ack 消息后，完成事务。 2.中断事务（假设有任何参与者反馈了 no 响应，或者超时了，就中断事务）。
发送中断请求：协调者向所有的参与者节点发送 abort 请求。
事务回滚：参与者接收到 abort 请求后，会利用其在二阶段记录的 undo 信息来执行事务回滚操作，并在完成回滚之后释放整个事务执行期间占用的资源。
反馈事务回滚结果：参与者在完成事务回滚之后，想协调者发送 Ack 消息。
中断事务：协调者接收到所有的 Ack 消息后，中断事务。
2.3.4与 2pc 的区别注意：在阶段三，可能会出现 2 种故障：协调者出现问题/协调者和参与者之间的网络故障一段出现了任一一种情况，最终都会导致参与者无法收到 doCommit 请求或者 abort 请求， 针对这种情况，参与者都会在等待超时之后，继续进行事务提交。
优点：
相比较 2PC，最大的优点是减少了参与者的阻塞范围（第一个阶段是不阻塞的），并且能够在单点故障后继续达成一致（2PC 在提交阶段会出现此问题，而 3PC 会根据协调者的状态进行回滚或者提交）。
缺点：
如果参与者收到了 preCommit 消息后，出现了网络分区，那么参与者等待超时后，都会进行事务的提交，这必然会出现事务不一致的问题。
2.4 TCC 方案TCC 其实就是采用的补偿机制，其核心思想是：针对每个操作，都要注册一个与其业务逻辑对应的确认和补偿（撤销）操作。
其将整个业务逻辑的每个分支显式的分成了 Try、Confirm、Cancel 三个操作。Try 部分完成业务的准备工作，confirm 部分完成业务的提交，cancel 部分完成事务的回滚。
优点：跟 2PC 比起来，实现以及流程相对简单了一些，但数据的一致性比 2PC 也要差一些
缺点：TCC 属于应用层的一种补偿方式，所以需要程序员在实现的时候多写很多补偿的代码，而且补偿的时候也有可能失败，在一些场景中，一些业务流程可能用TCC 不太好定义及处理。
2.5 MQ（事务消息）目前，仅阿里云的RocketMQ 支持事务消息。帮助用户实现类似 X/Open XA 的分布事务功能，通过 MQ 事务消息能达到分布式事务的最终一致。
说明：
发送方向 MQ 服务端发送消息
MQ Server 将消息持久化成功之后，向发送方 ACK 确认消息已经发送成功，此时消息为半消息
发送方开始执行本地事务逻辑
发送方根据本地事务执行结果向 MQ Server 提交二次确认（Commit 或是 Rollback），MQ Server 收到 Commit 状态则将半消息标记为可投递，订阅方最终将收到该消息；MQ Server 收到 Rollback 状态则删除半消息，订阅方将不会接受该消息
在断网或者是应用重启的特殊情况下，上述步骤 4 提交的二次确认最终未到达 MQ Server，经过固定时间后 MQ Server 将对该消息发起消息回查
发送方收到消息回查后，需要检查对应消息的本地事务执行的最终结果
发送方根据检查得到的本地事务的最终状态再次提交二次确认，MQ Server 仍按照步骤 4 对半消息进行操作
其中，事务消息发送对应步骤 1、2、3、4，事务消息回查对应步骤 5、6、7
2.6 Lcn 事务 2.6.1 背景LCN 名称是由早期版本的 LCN 框架命名，在设计框架之初的 1.0 ~ 2.0 的版本时框架设计的步骤是如下,各取其首字母得来的LCN 命名。
锁定事务单元（lock）
确认事务模块状态(confirm)
通知事务(notify)
2.6.2框架定位LCN 并不生产事务，LCN 只是本地事务的协调工,TX-LCN 定位于一款事务协调性框架，框架其本身并不操作事务，而是基于对事务的协调从而达到事务一致性的效果。
2.6.3事务控制原理TX-LCN 由两大模块组成, TxClient、TxManager
TxClient 作为模块的依赖框架，提供 TX-LCN 的标准支持
TxManager 作为分布式事务的控制方。事务发起方或者参与反都由TxClient 端来控制。
原理图：
1.创建事务组：是指在事务发起方开始执行业务代码之前先调用 TxManager 创建事务组对象，然后拿到事务标示 GroupId 的过程。
2.加入事务组：添加事务组是指参与方在执行完业务方法以后，将该模块的事务信息通知给 TxManager 的操作。