分布式事务在分布式系统经常遇见，但很多同学并了解分布式事务，下面重点详解四种主流分布式事务。
什么是分布式事务
分布式事务是指涉及多个计算机，或进程的一系列操作，这些操作需要保证在所有节点上的一致性和原子性。
如下图所示：
上图一次大的事务操作，由不同的小事务操作组成，这些小事务的操作分布在不同的服务器上，这些操作要么全部成功，要么全部失败。
分布式事务解决方案
常见的分布式事务解决方案，主要包含有以下四种：
两阶段提交协议
两阶段提交协议（Two-phase commit, 2PC）：该协议是目前最常用的分布式事务解决方案之一。
如下图所示:
第一阶段： prepare
每个参与者执行本地事务但不提交，进入 ready 状态，并通知协调者已经准 备就绪。
第二阶段：commit
当协调者确认每个参与者都 ready 后，通知参与者进行 commit 操作，如果有 参与者 fail ，则发送 rollback 命令，各参与者做回滚。
两阶段有如下几个缺点：
1.单点故障
一旦事务管理器出现故障，整个系统不可用，参与者都会阻塞住。
2.数据不一致
在阶段二，如果事务管理器只发送了部分 commit 消息，此时网络发生异常，那么 只有部分参与者接收到 commit 消息，也就是说只有部分参与者提交了事务，使得系统数据不一 致。
3.响应时间较长
参与者和协调者资源都被锁住，提交或者回滚之后才能释放。
三阶段提交协议
三阶段提交协议（Three-phase commit, 3PC）：3PC是2PC的改进版，它在2PC的基础上增加了一个“准备提交”阶段，以减少协调者单点故障的影响。
如下图所示：
分为三个阶段：
第一阶段：CanCommit阶段
协调者向参与者发送CanCommit请求，参与者如果可以提交就返回Yes响应，否则返回No响应。
第二阶段：PreCommit阶段
协调者根据参与者的反应情况来决定是否可以继续事务的PreCommit操作。
第三阶段：DoCommit阶段
协调者基于每个参与者PreCommit阶段的反馈结果，决定真正提交事务，还是中断事务。
当参与者节点收到“准备提交”请求时，它会向协调者发送“可以提交”，或“无法提交”的响应。
如果所有参与者节点都可以提交，则协调者通知所有参与者节点提交该事务，否则，协调者将询问所有参与者节点是否可以回滚该事务。
两阶段与三阶段对比：
补偿事务
补偿事务（Compensating transaction）：补偿事务是一种在分布式事务出现错误时回滚事务的方式。
如下图所示：
TCC 是一种补偿型事务，该模型要求应用的每个服务提供 try、confirm、cancel 三个接口。
TCC模型完全交由业务实现，每个子业务都需要实现Try-Confirm-Cancel三个接口，对业务侵入大，资源锁定交由业务方。
1、Try：尝试执行业务，完成所有业务检查(一致性)，预留必要的业务资源(准隔离性)。
2、Confirm：确认执行业务，不再做业务检查。只使用Try阶段预留的业务资源，Confirm操作满足幂等性。
3、Cancel：取消执行业务释放Try阶段预留业务资源。
最终一致性
最终一致性（Eventual consistency）：最终一致性是一种通过异步方式解决数据一致性问题的方案。
如下图所示：
该方案从本质上讲是将分布式事务转换为两个本地事务，然后依靠下游业务的重试机制达到最终一致性。
在最终一致性中，节点之间的数据同步是通过消息传递来实现的。
当节点之间的数据发生变化时，它们会通过异步方式将数据同步，最终，数据会达到一致状态，但这可能需要一段时间。
以上就是分布式事务解决方案详解，更多分布式系统方案，请查看：史上最强分布式系统详解(非常全面)。
陈睿mikechen
10年+大厂架构经验，资深技术专家，就职于阿里巴巴、淘宝、百度等一线互联网大厂。
关注「mikechen」公众号，获取更多技术干货！
后台回复【面试】即可获取《史上最全阿里Java面试题总结》，后台回复【架构】，即可获取《阿里架构师进阶专题全部合集》