概述
2PC，是Two-Phase-Commit的缩写，即二阶段提交，主要解决的问题是让基于分布式架构下的所有节点在进行事务处理过程中能够保证原子性和一致性。它的核心思想是“一票否决”。
提交过程(正如它的名字，它的提交分为两个阶段)
第一阶段：事务请求。由于在形式上近似是协调者组织各参与者对一次事务操作的投票表态过程，因此这一阶段也被称为“投票阶段”
a.事务询问。协调者向所有的参与者发送事务内容，询问是否可以执行事务提交操作，并开始等待各参与者的响应
b.执行事务。各参与者节点执行事务操作，并将Undo和Redo信息记入事务日志中
c.各参与者向协调者反馈事务询问的响应。如果参与者成功执行了事务操作，那么就反馈给协调者Yes响应，表示事务可以执行；如果参与者没有成功执行事务，那么就反馈给协调者No响应，表示事务不可以执行
第二阶段：事务提交。在第二阶段中，协调者会根据参与者的反馈情况来决定最终是否可以进行事务提交，正常情况下会包含两种可能：一是执行事务提交。二是中断事务
a. 执行事务提交。假如协调者从所有的参与者获得的反馈都是Yes响应，那么就会执行事务提交：
i.发送提交请求。协调者向所有参与者节点发出Commit请求
ii.事务提交。参与者接收到Commit请求后，会正式执行事务提交操作，并在完成提交之后释放在整个事务执行期间占用的事务资源
iii.反馈事务提交结果。参与者在完成事务提交之后，向协调者发送Ack消息
iiii.完成事务。协调者接收到所有参与者反馈的Ack消息后，完成事务提交
b. 中断事务。协调者获得的反馈只要有一个不是YES响应，就会执行回滚操作
i.发送回滚请求。协调者向所有参与者节点发出Rollback请求
ii.事务回滚。参与者接收到Rollback请求后，会利用其在阶段一中记录的Undo信息来执行事务回滚操作，并在完成回滚之后释放在整个事务执行期间占用的资源
iii.反馈事务回滚结果。参与者在完成事务回滚之后，向协调者发送Ack消息
iv. 中断事务。协调者接收到所有参与者反馈的Ack消息后，完成事务中断
2PC算法的缺点
a. 同步阻塞：二阶段提交协议存在的最明显也是最大的一个问题就是同步阻塞，这会极大地限制分布式系统的性能。在二阶段提交的执行过程中，所有参与该事务操作的逻辑都处于阻塞状态，也就是说，各个参与者在等待其他参与者响应的过程中，将无法进行其他任何操作
b. 单点问题：协调者的角色在整个二阶段提交协议中处于核心地位，因此一旦协调者出现问题，那么整个二阶段提交流程将无法运转
c. 太过保守：如果在协调者指示参与者进行事务提交询问的过程中，参与者出现故障而导致协调者始终无法获取到所有参与者的响应信息的话，这时协调者只能依靠其自身的超时机制来判断是否需要中断事务，这样的策略显得比较保守。换句话说，二阶段提交协议没有设计较为完善的容错机，任意一个节点的失败都会导致整个事务的失败
