分布式事务 两阶段提交 (2PC)

两阶段提交（2PC） 是 Oracle Tuxedo 系统提出的 XA 分布式事务协议的其中一种实现方式。

XA协议中有两个重要角色：事务协调者和事务参与者

既然叫两阶段提交，确定是分为两个阶段。

Java 生态下可使用atomikos来快速实现两阶段提交的分布式事务。

第一阶段

顺利的状况下

1. 事务协调者的节点会首先向全部的参与者节点发送 Prepare(预备) 请求。
2. 在接到 Prepare(预备) 请求以后，每个参与者节点会各自执行与事务有关的数据更新，写入Undo Log和Redo Log。
3. 参与者执行成功，暂时不提交事务，向事务协调节点返回 done(完成) 消息。
4. 进入第二阶段

出错时

在XA的第一阶段，若是某个事务参与者反馈失败消息，说明该节点的本地事务执行不成功，必须回滚。

1. 事务协调者的节点会首先向全部的参与者节点发送 Prepare(预备) 请求。
2. 在接到 Prepare(预备) 请求以后，每个参与者节点会各自执行与事务有关的数据更新，写入Undo Log和Redo Log。
3. 参与者执行失败，返回失败消息。
4. 协调者中断事务

中断事物

任何一个参与者向协调者反馈了 No 响应，或者在等待超时以后，协调者尚没法接收到全部参与者的反馈响应，那么就会中断事物。

1. 发送回滚请求。协调者向全部参与者节点发出 Rollback 请求。
2. 事物回滚。参与者收到Rollback请求以后，会利用其在阶段一种记录的 Undo 信息来执行事务回滚操做，并在完成回滚以后释放在整个事物执行期间占用的资源。
3. 反馈事物回滚结果。参与者在完成事物回滚以后，向协调者发送 Ack 消息。
4. 中断事务

第二阶段

在XA分布式事务的第二阶段，若是事务协调节点在以前所收到都是正向返回，那么它将会向全部事务参与者发出Commit请求。

接到Commit请求以后，事务参与者节点会各自进行本地的事务提交，并释放锁资源。当本地事务完成提交后，将会向事务协调者返回“完成”消息。

当事务协调者接收到全部事务参与者的“完成”反馈，整个分布式事务完成。

缺点

1. 两阶段提交涉及屡次节点间的网络通讯，通讯时间长！且在整个过程当中，全部节点都处于阻塞状态，全部节点所持有的资源（例如数据库数据，本地文件等）都处于锁定状态

2. 单点故障。因为协调者的重要性，一旦协调者发生故障。参与者会一直阻塞下去。尤为在第二阶段，协调者发生故障，那么全部的参与者还都处于锁定事务资源的状态中，而没法继续完成事务操做。（若是是协调者挂掉，能够从新选举一个协调者，可是没法解决由于协调者宕机致使的参与者处于阻塞状态的问题）

3. 数据不一致。在二阶段提交的阶段二中，当协调者向参与者发送commit请求以后，发生了局部网络异常或者在发送commit请求过程当中协调者发生了故障，这回致使只有一部分参与者接受到了commit请求。而在这部分参与者接到commit请求以后就会执行commit操做。可是其余部分未接到commit请求的机器则没法执行事务提交。因而整个分布式系统便出现了数据不一致性的现象。