分布式存储的三阶段提交协议
三阶段提交是为解决两阶段提交协议的缺点而设计的。与两阶段提交不同的是，三阶段提交是“非阻塞”协议。三阶段提交在两阶段提交的第一阶段与第二阶段之间插入了一个准备阶段，使得原先在两阶段提交中，参与者在投票之后，由于协调者发生崩溃或错误，而导致参与者处于无法知晓是否提交或者中止的“不确定状态”所产生的可能相当长的延时的问题得以解决。
三阶段如下：
阶段1：CanCommit。3PC.CanCommit == 2PC.Request
（1）事务询问：协调者向参与者发送CanCommit请求，询问是否可以执行事务提交操作，然后开始等待参与者的响应。
（2）响应反馈：参与者接到CanCommit请求后，如果认为可以执行，返回Yes，并进入预备状态；否则返回No。
阶段2：PreCommit
（1）协调者接收到的都是Yes，那么执行事务的预提交。
发送预提交请求：协调者向参与者发送PreCommit请求，并进入Prepared阶段。
事务预提交：参与者接收到PreCommit请求后，会执行事务操作，并将Undo和Redo信息记录到事务日志中。
响应反馈：如果参与者成功执行了事务操作，则返回Ack响应，同时开始等待最终指令。
（2）协调者接收到至少一个No，或者至少有一个超时，则执行事务的中断。
发送中断请求：协调者向所有参与者发生Abort请求。
中断事务：参与者收到协调者的Abort请求，或者超时仍未收到协调者请求时，执行事务的中断。
阶段3：DoCommit，事务真正提交阶段
（1）执行提交
发送提交请求：协调者接收到参与者发送的Ack响应后，从预提交状态进入提交状态，并向所有参与者发生DoCommit请求。
事务提交：参与者接收到DoCommit请求后，执行正式的事务提交，并在完成事务提交后释放所有事务资源。
响应反馈：事务提交完成后，向协调者发送Ack响应。
完成事务：协调者接收到所有参与者的Ack响应后，完成事务。
（2）中断事务
发送中断请求：协调者向所有参与者发送Abort请求。
事务回滚：参与者接收到Abort请求后，利用在阶段2记录的Undo信息执行事务回滚操作，并在完成回滚后释放所有的事务资源。
反馈结果：参与者完成回滚后，向协调者发送Ack消息。
中断事务：协调者接收到参与者反馈的Ack消息后，执行事务的中断。
