2PC
二阶段提交就是将事务的提交过程分成了两个阶段来进行处理。
阶段一
事务询问
协调者向所有的参与者询问，是否准备好了执行事务，并开始等待各参与者的响应。执行事务
各参与者节点执行事务操作，并将 Undo 和 Redo 信息记入事务日志中各参与者向协调者反馈事务询问的响应
如果参与者成功执行了事务操作，那么就反馈给协调者 Yes 响应，表示事务可以执行；如果参与者没有成功执行事务，就返回 No 给协调者，表示事务不可以执行。
阶段二
根据阶段一的投票结果执行两种操作：执行事务提交or中断事务。
执行事务提交：
- 发送提交请求：协调者向所有参与者发出 commit 请求。
- 事务提交：参与者收到 commit 请求后，会正式执行事务提交操作，并在完成提交之后释放整个事务执行期间占用的事务资源。
- 反馈事务提交结果：参与者在完成事务提交之后，向协调者发送 Ack 信息。
- 协调者接收到所有参与者反馈的 Ack 信息后，完成事务。
中断事务：
- 发送回滚请求：协调者向所有参与者发出 Rollback 请求。
- 事务回滚：参与者接收到 Rollback 请求后，会利用其在阶段一种记录的 Undo 信息来执行事务回滚操作，并在完成回滚之后释放在整个事务执行期间占用的资源。
- 反馈事务回滚结果：参与者在完成事务回滚之后，想协调者发送 Ack 信息。
- 中断事务：协调者接收到所有参与者反馈的 Ack 信息后，完成事务中断。
优缺点
优点：原理简单，实现方便
缺点：同步阻塞，单点问题，数据不一致，过于保守
同步阻塞：
在二阶段提交的过程中，所有的节点都在等待其他节点的响应，无法进行其他操作。这种同步阻塞极大的限制了分布式系统的性能。
单点问题：
协调者在整个二阶段提交过程中很重要，如果协调者在提交阶段出现问题，那么整个流程将无法运转，更重要的是：其他参与者将会处于一直锁定事务资源的状态中，而无法继续完成事务操作。
数据不一致：
假设当协调者向所有的参与者发送 commit请求之后，发生了局部网络异常或者是协调者在尚未发送完所有 commit 请求之前自身发生了崩溃，导致最终只有部分参与者收到了 commit 请求。这将导致严重的数据不一致问题。
过于保守：
如果在二阶段提交的提交询问阶段中，参与者出现故障而导致协调者始终无法获取到所有参与者的响应信息的化，这时协调者只能依靠其自身的超时机制来判断是否需要中断事务，显然，这种策略过于保守。换句话说，二阶段提交协议没有设计较为完善的容错机制，任意一个节点是失败都会导致整个事务的失败
3PC
三阶段提交，是 2PC 的改进版，其将 2PC 的 “提交事务请求” 过程一分为二。
阶段一：CanCommit
- 务询问：协调者向所有的参与者发送一个包含事务内容的 canCommit 请求，询问是否可以执行事务提交操作，并开始等待各参与者的响应。
- 各参与者向协调者反馈事务询问的响应：参与者接收来自协调者的 canCommit 请求，如果参与者认为自己可以顺利执行事务，就返回 Yes，否则反馈 No 响应。
阶段二：PreCommit
协调者在得到所有参与者的响应之后，会根据结果执行2种操作：执行事务预提交，或者中断事务。
执行事务预提交
- 发送预提交请求：协调者向所有参与者节点发出 preCommit 的请求，并进入 prepared 状态。
- 事务预提交：参与者受到 preCommit 请求后，会执行事务操作，对应 2PC 中的 “执行事务”，也会 Undo 和 Redo 信息记录到事务日志中。
- 各参与者向协调者反馈事务执行的结果：如果参与者成功执行了事务，就反馈 Ack 响应，同时等待指令：提交（commit） 或终止（abor）。
中断事务
- 发送中断请求：协调者向所有参与者节点发出 abort 请求 。
- 中断事务：参与者如果收到 abort 请求或者超时了，都会中断事务。
阶段三：do Commit
该阶段做真正的提交，同样也会出现两种情况：
执行提交
- 发送提交请求：进入这一阶段，如果协调者正常工作，并且接收到了所有协调者的 Ack 响应，那么协调者将从 “预提交” 状态变为 “提交” 状态，并向所有的参与者发送 doCommit 请求 。
- 事务提交：参与者收到 doCommit 请求后，会正式执行事务提交操作，并在完成之后释放在整个事务执行期间占用的事务资源。
- 反馈事务提交结果：参与者完成事务提交后，向协调者发送 Ack 消息。
- 完成事务：协调者接收到所有参与者反馈的 Ack 消息后，完成事务。
中断事务
假设有任何参与者反馈了 no 响应，或者超时了，就中断事务。
- 发送中断请求：协调者向所有的参与者节点发送 abort 请求。
- 事务回滚：参与者接收到 abort 请求后，会利用其在二阶段记录的 undo 信息来执行事务回滚操作，并在完成回滚之后释放整个事务执行期间占用的资源。
- 反馈事务回滚结果：参与者在完成事务回滚之后，向协调者发送 Ack 消息。
一旦进入阶段三，可能会出现 2 种故障：
协调者出现问题
协调者和参与者之间的网络故障
出现了任一种情况，最终都会导致参与者无法收到 doCommit 请求或者 abort 请求，针对这种情况，参与者都会在等待超时之后，继续进行事务提交。
优缺点
优点
减少了参与者的阻塞范围（第一个阶段是不阻塞的），并且能够在单点故障后继续达成一致（2PC 在提交阶段会出现此问题，而 3PC 会根据协调者的状态进行回滚或者提交）。
缺点
如果参与者收到了 preCommit 消息后，出现了网络分区，那么参与者等待超时后，都会进行事务的提交，这必然会出现事务不一致的问题。
