二阶段提交协议：

• 准备阶段：又叫作投票阶段，在这一阶段，协调者询问事务的所有参与者是否准备好提交，参与者如果已经准备好提交则回复 Prepared，否则回复 Non-Prepared。这里所说的准备操作跟人类语言中通常理解的准备并不相同，对于数据库来说，准备操作是在重做日志中记录全部事务提交操作所要做的内容，它与本地事务中真正提交的区别只是暂不写入最后一条 Commit Record 而已，这意味着在做完数据持久化后并不立即释放隔离性，即仍继续持有锁，维持数据对其他非事务内观察者的隔离状态。
• 提交阶段：又叫作执行阶段，协调者如果在上一阶段收到所有事务参与者回复的 Prepared 消息，则先自己在本地持久化事务状态为 Commit，在此操作完成后向所有参与者发送 Commit 指令，所有参与者立即执行提交操作；否则，任意一个参与者回复了 Non-Prepared 消息，或任意一个参与者超时未回复，协调者将自己的事务状态持久化为 Abort 之后，向所有参与者发送 Abort 指令，参与者立即执行回滚操作。对于数据库来说，这个阶段的提交操作应是很轻量的，仅仅是持久化一条 Commit Record 而已，通常能够快速完成，只有收到 Abort 指令时，才需要根据回滚日志清理已提交的数据，这可能是相对重负载的操作。

二阶段提交协议在准备阶段失败（回滚）了可以补救，但是在提交阶段失败了是无法补救的 （不再改变提交或者回滚的结果，只能等待崩溃的节点重新恢复）。因此提交阶段要求耗时尽量短。二阶段提交协议要求网络在提交阶段的短时间内是可靠的，即提交阶段不会丢失消息。

FLP不可能理论：如果宕机最后不能恢复，那就不存在任何一种分布式协议可以正确地达成一致性结果。

三阶段提交协议：三阶段提交协议把二阶段的准备阶段再细分为两个阶段，分为CanCommit和PreCommit，把提交阶段改为DoCommit阶段。新增的CanCommit阶段是一个询问阶段，协调者让每个参与者根据自身的状态评估该事务是否有可能顺利完成。三阶段提交协议拆分理由为：准备阶段是一个重负载的操作，一旦协调者发出开始准备的消息，每个参与者都将马上开始写重做日志，他们所涉及到的数据资源即将被锁住，如果此时一个参与者宣告无法完成提交，相当于大家都做了一轮无用功。新增一个询问阶段，如果都得到了正面的响应，那么事务能够提交的把握就比较到了，这也意味着某个参与者提交时发生崩溃导致大家全部回滚的风险相对变小。

在事务需要回滚的场景中，三阶段提交协议性能通常比二阶段要好得多，但在事务能够正常提交的场景下，三阶段提交协议多了一次询问，性能要比二阶段提交协议差，但是两者的性能都好不到哪去。