三阶段提交协议 (Three-phase commit protocol, 3PC) 通常被认为是 2PC 的升级版，可以保证一个事务跨越多个节点时保持 ACID 特性。
在三阶段提交协议中，系统一般包含两类机器（或节点）：一类为协调者（coordinator），通常一个系统中只有一个；另一类为事务参与者（participants，cohorts或workers），一般包含多个。
运行过程
第一阶段(CanCommit)
该阶段协调者会去询问各个参与者是否能够正常执行事务，参与者根据自身情况回复一个预估值，相对于真正的执行事务，这个过程是轻量的，具体步骤如下：
1.1 事务询问：协调者向各个参与者发送事务询问通知，询问是否可以执行事务操作，并等待回复
1.2 反馈响应：各个参与者依据自身状况回复一个预估值，如果预估自己能够正常执行事务就返回确定信息，并进入预备状态，否则返回否定信息
第二阶段(PreCommit)**
本阶段协调者会根据第一阶段的询盘结果采取相应操作，询盘结果主要有三种：
2.1 所有的参与者都返回确定信息
2.2 一个或多个参与者返回否定信息
2.3 协调者等待超时。
针对第一种情况，协调者会向所有参与者发送事务执行请求：
2.1.1 协调者向所有的事务参与者发送事务执行通知
2.1.2 参与者收到通知后，执行事务，但不提交
2.1.3 参与者将事务执行情况返回给客户端
在上面的步骤中，如果参与者等待超时，则会中断事务。 针对第二、三种情况，协调者认为事务无法正常执行，于是向各个参与者发出 abort 通知，请求退出预备状态：
2.2.1 协调者向所有事务参与者发送 abort 通知
2.2.2 参与者收到通知后，中断事务
第二阶段(DoCommit)**
如果第二阶段事务未中断，那么本阶段协调者将会依据事务执行返回的结果来决定提交或回滚事务，分为三种情况：
3.1 所有的参与者都能正常执行事务
3.2 一个或多个参与者执行事务失败
3.3 协调者等待超时
针对第一种情况，协调者向各个参与者发起事务提交请求：
3.1.1 协调者向所有参与者发送事务 commit 通知
3.1.2 所有参与者在收到通知之后执行 commit 操作，并释放占有的资源
3.1.3 参与者向协调者反馈事务提交结果
针对第二、三种情况，协调者认为事务无法正常执行，于是向各个参与者发送事务回滚请求:
3.2.1 协调者向所有参与者发送事务 rollback 通知
3.2.2 所有参与者在收到通知之后执行 rollback 操作，并释放占有的资源
3.2.3 参与者向协调者反馈事务提交结果
和 2PC 的不同
对于协调者和参与者都设置了超时机制（在 2PC 中，只有协调者拥有超时机制，即如果在一定时间内没有收到参与者的消息则默认失败）。 在 2PC 的准备阶段和提交阶段之间，插入预提交阶段，使 3PC 拥有 CanCommit、 PreCommit、 DoCommit三个阶段。 PreCommit是一个缓冲，保证了在最后提交阶段之前各参与节点的状态是一致的。
优缺点
优点
3PC 协议最大的优点是降低了参与者的阻塞范围，并且能够在出现单点故障后继续达成一致。
缺点
在参与者接收到 PreCommit 消息后，如果出现网络分区，此时协调者所在的节点和参与者无法进行正常网络通信，在这种情况下，该参与者依然会进行实物提交，会导致数据不一致。
