2PC协议就是两阶段提交，用来解决分布式事务，分为两个阶段，分别为Prepare和Commit，也是PC由来。
第一阶段Prepare 提交事务请求
如图所示，主要流程有以下三个方面
-
询问：事务协调者(Manager)向所有的事务参与者发送事务请求，询问是否可能执行事务，然后等待各个待各个事务参与者的响应。
-
执行：各个事务参与者在接收到事务协调者的请求后，开始执行事务操作，并将undo、redo信息记录到事务日志中去。
-
响应：如果参与者成功执行了事务并记录了undo、redo日志，则向事务协调者返回YES，否则返回NO，当然了在实际中也可能存在参与者宕机就一直得不到响应的情况。
第二阶段Commit 执行事务提交
两种情况，一种是成功执行commit，另一种是执行失败rollback
执行成功commit，流程图
-
commit请求：事务协调者向所有的事务参与者发送事务commit请求。所有的事务参与者在接收到协调者的请求后，执行事务提交操作，执行完成后释放在事务执行期间占用的系统资源。
-
反馈结果：参与者执行完事务提交后向协调者发送Ack响应。
-
完成事务：协调者在接收到所有事务参与者的Ack响应后完成事务提交。
执行失败rollback
在执行Prepare阶段，难免的可能会出现如下情况：
-
参与者执行事务失败
-
参与者服务宕机
-
协调者与参与者网络通信中断
如果出行以上情况，这时协调者就无法接收到参与者的YES响应或者某一个参与者返回了NO响应，这时协调者就进入到了事务rollback回滚阶段，对事务进行回滚操作。如下图
-
rollback请求：事务协调者向所有的事务参与者发送事务rollback回滚请求。
-
参与者在接收到协调者的rollback回滚操作后，会根据在Prepare阶段记录的undo日志进行事务回滚，完成事务回滚后会释放掉在事务回滚执行期间占用的所有资源。
-
结果反馈：参与者完成事务rollback回滚后会向协调者发送Ack响应。
-
完成事务：事务协调者在接收到所有事务参与者的Ack响应后完成事务rollback回滚。
可能存在的问题
-
同步阻塞：在参与者等待协调者的指令的时候，实质上是在等待参与者的响应，在这期间参与者就不能进行任何其他的操作，也就是阻塞了其运行。如果发生了协调者与参与者不能进行网络通信的情况，参与者一直接收不到协调者的指令，那么参与者将会一直阻塞下去。
-
单点：在2PC中，一切请求都来自协调者，所以协调者的地位是至关重要的，如果协调者宕机，那么就会使参与者一直阻塞并一直占用资源。如果协调者也是分布式，使用选主方式提供服务，那么在一个协调者挂掉后，可以选取另一个协调者继续后续的服务，可以解决单点问题。但是，新协调者无法知道上一个事务的全部状态信息（例如已等待Prepare响应的时长等），所以也无法顺利处理上一个事务。
-
数据不一致：Commit事务过程中，Commit/Rallback请求可能因为协调者宕机或协调者与参与者网络问题丢失，那么就导致了部分参与者没有收到Commit/Rallback请求，而其他参与者则正常收到执行了Commit/Rallback操作，没有收到请求的参与者继续阻塞。这时参与者之间的数据就不再一致了。
-
环境可靠性依赖：协调者Prepare请求发出后，等待响应，然而如果有参与者宕机或与协调者之间的网络中断，都会导致协调者无法收到所有参与者的响应，那么在2PC中，协调者会等待一定时间，然后超时后，会触发事务回滚。在这个过程中，协调者和所有参与者都是出于阻塞的。这种机制对网络问题常见的现实环境来说太苛刻了。
