关于java:分布式事务之两阶段提交2PC

两阶段提交（2PC） 是 Oracle Tuxedo 零碎提出的 XA 分布式事务协定的其中一种实现形式。

一、对于 XA 分布式事务协定

XA 分布式协定次要有两个角色：

• 事务管理器（协调者）
  事务管理器作为全局事务的协调管理者，与每个资源管理器通信，实现分布式事务的治理。
• 资源管理器（参与者）
  资源管理器治理每个参与者的事务资源，其应该具备提交和回滚的能力，如数据库。

XA 分布式协定制订的分段提交过程：

• 第一阶段（prepare）
  第一阶段每个参与者筹备执行事务并对须要的资源加锁，进入 ready 状态，并告诉协调者曾经准备就绪。
• 第二阶段（commit）
  第二阶段当协调者确认每个参与者都 ready 后，告诉参与者进行 commit 操作；如果有参与者 fail，则发送 rollback 命令，各参与者做回滚。

二、两阶段提交（2PC）

基于 XA 协定，有了两阶段提交的实现，在 JAVA 中能够应用基于两阶段提交的 atomikos 来进行分布式事务管理。

了解起来其实很简略，上面就从 2PC 的不同阶段和不同的状态来剖析它的执行过程：

第一阶段

• 各参与者都胜利的状况
  

  1. 首先事务协调者向所有参与者发送 prepare 申请。
  2. 参与者开始执行各自的数据更新，写入各自的 Undo Log 和 Redo Log。
  3. 参与者执行胜利后，临时不提交事务，向协调者发送 Done 音讯。
  4. 进入第二阶段。

• 有参与者失败的状况
  

  在第一阶段，如果参与者在本地事务中执行失败，会向协调者发送 Fail 音讯，协调者产生事务中断。

• 事务中断

任何一个参与者向协调者反馈了 Fail 音讯，或者在期待超时之后，协调者不能接管到参与者的反馈响应，就会中断事务。

步骤如下：

1. 协调者向所有参与者收回 Rollback 申请。
2. 参与者收到 Rollback 申请之后，会利用其在阶段一种记录的 Undo 信息来执行事务回滚操作，并在实现回滚之后开释在整个事物执行期间占用的资源。
3. 参与者在实现事物回滚之后，向协调者发送 Ack 音讯。
4. 中断事务

第二阶段

第二阶段中，如果所有参与者的都执行胜利，则协调者下发 Commit 音讯，参与者提交本地事务，开释锁住的资源，并向协调者发送 Ack 确认。

当协调者受到所有的参与者确认音讯后，整个分布式事务完结。

三、总结

基于以上，能够很容易了解 2PC 的执行过程，同时咱们也留神到它存在的毛病：

1. 对高并发不敌对。
   在分布式事务的执行过程中，存在屡次通信，占用工夫长，并且在这个过程中所有节点处于阻塞状态，每个参与者持有的资源始终要加锁。
2. 单点故障。由下面可知协调者扮演着十分重要的角色，一旦协调者产生故障，参与者就会始终阻塞上来。尤其在第二阶段，协调者产生故障，那么所有的参与者还都处于锁定事务资源的状态中，而无奈持续实现事务操作。
3. 数据不统一。在第二阶段中，当协调者向参与者发送 commit 申请之后，产生了部分网络异样或者在发送 commit 申请过程中协调者产生了故障，就会导致只有一部分参与者承受到了 commit 申请。而在这部分参与者接到 commit 申请之后就会执行 commit 操作，然而其余未接到 commit 申请的机器则无奈执行事务提交，就导致了数据的不统一。

欢送拜访集体博客 获取更多常识分享。