这是我参与「第五届青训营 」伴学笔记创作活动的第 5 天

二阶段提交

定义： 为了使基于分布式系统架构下的所有节点在进行事务提交时保持一致性而设计的一种演算法。

两阶段提交协议可以保证数据的强一致性，即保证了分布式事务的原子性

三个假设：

1. 引入协调者和参与者，互相进行网络通信
2. 所有节点都采用预写式日志，且日志被写入后即被保持在可靠的存储设备上
3. 所有节点不会永久性损坏，即使损坏后仍然可以恢复

可能出现的情况：

情况1) Coordinator不宕机，Participant宕机。如下图所示，需要进行回滚操作 情况2)Coordinator宕机，Participant不宕机。可以起新的协调者，待查询状态后，重复二阶段提交 情况3) Coordinator宕机，Participant宕机 回滚: 在Prepare阶段，如果某个事务参与者反馈失败消息，说明该节点的本地事务执行不成功，必须回滚

情况3无法确认状态，需要数据库管理员的介入，防止数据库进入一个不一致的状态

两阶段提交面临的挑战

1. 性能问题

   两阶段提交需要多次节点间的网络通信，耗时过大，资源需要进行锁定，徒增资源等待时间

2. 协调者单点故障问题

   如果事务协调者节点宕机，需要另起新的协调者，否则参与者处于中间状态无法完成事务

3. 网络分区带来的数据不一致

   一部分参与者收到了Commit消息，另一部分参与者没收到Commit消息，会导致节点之间的数据不一致

三阶段提交

三阶段提交协议可以理解为两阶段提交协议的改良版，是在协调者和参与者中都引入超时机制，并且把两阶段提交协议的第一个阶段分成了两步: 询问，然后再锁资源，最后真正提交。减少因为最后提交失败而造成多余的网络通信。

三阶段提交分为以下三个阶段：

• CanCommit
• PreCommit
• DoCommit

三阶段提交主要解决的单点故障问题，并减少阻塞，因为一旦参与者无法及时收到来自协调者的信息之后，他会默认执行commit。而不会一直持有事务资源并处于阻塞状态。但是这种机制也会导致数据一致性问题，因为，由于网络原因，协调者发送的abort响应没有及时被参与者接收到，那么参与者在等待超时之后执行了commit操作。这样就和其他接到abort命令并执行回滚的参与者之间存在数据不一致的情况。