两阶段提交2PC是分布式事务中最强大的事务类型之一，两段提交就是分两个阶段提交：

• 第一阶段询问各个事务数据源是否准备好。
• 第二阶段才真正将数据提交给事务数据源。
  为了保证该事务可以满足ACID，就要引入一个协调者（Cooradinator）。其他的节点被称为参与者（Participant）。协调者负责调度参与者的行为，并最终决定这些参与者是否要把事务进行提交。

处理流程如下：

阶段一

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

阶段二

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

情况1：当所有参与者均反馈 yes，提交事务

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

情况2：当有一个参与者反馈 no，回滚事务

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

存在的问题：

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

优点：
尽量保证了数据的强一致，适合对数据强一致要求很高的关键领域。（其实也不能100%保证强一致）。

缺点：
实现复杂，牺牲了可用性，对性能影响较大，不适合高并发高性能场景。