共计 1278 个字符，预计需要花费 4 分钟才能阅读完成。
两阶段提交（2PC） 是 Oracle Tuxedo 零碎提出的 XA 分布式事务协定的其中一种实现形式。
一、对于 XA 分布式事务协定
XA 分布式协定次要有两个角色：
- 事务管理器（协调者）
事务管理器作为全局事务的协调管理者，与每个资源管理器通信，实现分布式事务的治理。 - 资源管理器（参与者）
资源管理器治理每个参与者的事务资源，其应该具备提交和回滚的能力，如数据库。
XA 分布式协定制订的分段提交过程：
- 第一阶段（prepare）
第一阶段每个参与者筹备执行事务并对须要的资源加锁，进入 ready 状态，并告诉协调者曾经准备就绪。 - 第二阶段（commit）
第二阶段当协调者确认每个参与者都 ready 后，告诉参与者进行 commit 操作；如果有参与者 fail，则发送 rollback 命令，各参与者做回滚。
二、两阶段提交（2PC）
基于 XA 协定，有了两阶段提交的实现，在 JAVA 中能够应用基于两阶段提交的 atomikos 来进行分布式事务管理。
了解起来其实很简略，上面就从 2PC 的不同阶段和不同的状态来剖析它的执行过程：
第一阶段
-
各参与者都胜利的状况
- 首先事务协调者向所有参与者发送 prepare 申请。
- 参与者开始执行各自的数据更新，写入各自的 Undo Log 和 Redo Log。
- 参与者执行胜利后，临时不提交事务，向协调者发送 Done 音讯。
- 进入第二阶段。
-
有参与者失败的状况
在第一阶段，如果参与者在本地事务中执行失败，会向协调者发送 Fail 音讯，协调者产生事务中断。
- 事务中断
任何一个参与者向协调者反馈了 Fail 音讯，或者在期待超时之后，协调者不能接管到参与者的反馈响应，就会中断事务。
步骤如下：
- 协调者向所有参与者收回 Rollback 申请。
- 参与者收到 Rollback 申请之后，会利用其在阶段一种记录的 Undo 信息来执行事务回滚操作，并在实现回滚之后开释在整个事物执行期间占用的资源。
- 参与者在实现事物回滚之后，向协调者发送 Ack 音讯。
- 中断事务
第二阶段
第二阶段中，如果所有参与者的都执行胜利，则协调者下发 Commit 音讯，参与者提交本地事务，开释锁住的资源，并向协调者发送 Ack 确认。
当协调者受到所有的参与者确认音讯后，整个分布式事务完结。
三、总结
基于以上，能够很容易了解 2PC 的执行过程，同时咱们也留神到它存在的毛病：
- 对高并发不敌对。
在分布式事务的执行过程中，存在屡次通信，占用工夫长，并且在这个过程中所有节点处于阻塞状态，每个参与者持有的资源始终要加锁。- 单点故障。由下面可知协调者扮演着十分重要的角色，一旦协调者产生故障，参与者就会始终阻塞上来。尤其在第二阶段，协调者产生故障，那么所有的参与者还都处于锁定事务资源的状态中，而无奈持续实现事务操作。
- 数据不统一。在第二阶段中，当协调者向参与者发送 commit 申请之后，产生了部分网络异样或者在发送 commit 申请过程中协调者产生了故障，就会导致只有一部分参与者承受到了 commit 申请。而在这部分参与者接到 commit 申请之后就会执行 commit 操作，然而其余未接到 commit 申请的机器则无奈执行事务提交，就导致了数据的不统一。
欢送拜访集体博客 获取更多常识分享。
正文完