2PC其实就是两阶段提交的分布式事务中事务类型，两阶段提交就是分两个阶段提交：

第一阶段询问各个事务数据源是否准备好。
第二阶段才真正将数据提交给事务数据源。

为了保证该事务可以满足ACID，就引入一个协调者（Cooradinator）。其他的节点被称为参与者（Participant）。协调者负责调度参与者的行为，并最终决定这些参与者是否要把事务进行提交。 处理流程如下：

 阶段一

a) 协调者向所有参与者发送事务内容，询问是否可以提交事务，并等待答复。
b) 各参与者执行事务操作，将 undo 和 redo 信息记入事务日志中（但不提交事务）。
c) 如参与者执行成功，给协调者反馈 yes，否则反馈 no。

阶段二

如果协调者收到了参与者的失败消息或者超时，直接给每个参与者发送回滚(rollback)消息；否则发送提交(commit)消息。

两种情况处理如下：

情况1：当所有参与者均反馈 yes，提交事务
a) 协调者向所有参与者发出正式提交事务的请求（即 commit 请求）。
b) 参与者执行 commit 请求，并释放整个事务期间占用的资源。
c) 各参与者向协调者反馈 ack(应答)完成的消息。
d) 协调者收到所有参与者反馈的 ack 消息后，即完成事务提交。

情况2：当有一个参与者反馈 no，回滚事务
a) 协调者向所有参与者发出回滚请求（即 rollback 请求）。
b) 参与者使用阶段 1 中的 undo 信息执行回滚操作，并释放整个事务期间占用的资源。
c) 各参与者向协调者反馈 ack 完成的消息。
d) 协调者收到所有参与者反馈的 ack 消息后，即完成事务。

缺陷问题

1) 性能问题：所有参与者在事务提交阶段处于同步阻塞状态，占用系统资源，容易导致性能瓶颈。
2) 可靠性问题：如果协调者存在单点故障问题，或出现故障，提供者将一直处于锁定状态。
3) 数据一致性问题：在阶段 2 中，如果出现协调者和参与者都挂了的情况，有可能导致数据不一致。

优点：尽量保证了数据的强一致，适合对数据强一致要求很高的关键领域。（其实也不能100%保证强一致）。
缺点：实现复杂，牺牲了可用性，对性能影响较大，不适合高并发高性能场景。