二阶段提交和三阶段提交算法的理解

一、二阶段提交算法的描述：

二阶段提交算法的成立基于以下假设：

1. 该分布式系统中，存在一个节点作为协调者(Coordinator)，其他节点作为参与者(Cohorts)。且节点之间可以进行网络通信。
2. 所有节点都采用预写式日志，且日志被写入后即被保持在可靠的存储设备上，即使节点损坏不会导致日志数据的消失。
3. 所有节点不会永久性损坏，即使损坏后仍然可以恢复。

以下对二阶段提交算法分阶段进行说明。

第一阶段(提交请求阶段)

1. 协调者节点向所有参与者节点询问是否可以执行提交操作，并开始等待各参与者节点的响应。
2. 参与者节点执行询问发起为止的所有事务操作，并将Undo信息和Redo信息写入日志。
3. 各参与者节点响应协调者节点发起的询问。如果参与者节点的事务操作实际执行成功，则它返回一个"同意"消息；如果参与者节点的事务操作实际执行失败，则它返回一个"中止"消息。

有时候，第一阶段也被称作投票阶段，即各参与者投票是否要继续接下来的提交操作。

第二阶段(提交执行阶段)

成功

当协调者节点从所有参与者节点获得的相应消息都为"同意"时：

1. 协调者节点向所有参与者节点发出"正式提交"的请求。
2. 参与者节点正式完成操作，并释放在整个事务期间内占用的资源。
3. 参与者节点向协调者节点发送"完成"消息。
4. 协调者节点受到所有参与者节点反馈的"完成"消息后，完成事务。

失败

如果任一参与者节点在第一阶段返回的响应消息为"中止"，或者 协调者节点在第一阶段的询问超时之前无法获取所有参与者节点的响应消息时：

1. 协调者节点向所有参与者节点发出"回滚操作"的请求。
2. 参与者节点利用之前写入的Undo信息执行回滚，并释放在整个事务期间内占用的资源。
3. 参与者节点向协调者节点发送"回滚完成"消息。
4. 协调者节点受到所有参与者节点反馈的"回滚完成"消息后，取消事务。

有时候，第二阶段也被称作完成阶段，因为无论结果怎样，协调者都必须在此阶段结束当前事务

以上的内容均来自于维基百科，可以参见：http://zh.wikipedia.org/wiki/%E4%BA%8C%E9%98%B6%E6%AE%B5%E6%8F%90%E4%BA%A4

理解：

1、二阶段提交的整个过程是比较容易理解的

2、二阶段协议的理解必须建立在之前的假设之上，即日志写在可靠磁盘上，也就是说，基于日志的事务提交是可靠的。

3、二阶段算法的最大缺陷是资源的阻塞，尤其是某个参与者在第一阶段执行过程中发生故障的时候，资源会长久性的阻塞。

基于对二阶段问题的解决，三阶段提交在两阶段提交的第一阶段与第二阶段之间插入了一个准备阶段，并且引入了超时机制，为什么要加一个准备阶段：

1、在投票阶段可以不用阻塞资源

2、通常来讲，投票通过以后，准备阶段失败的概率会比较低，并且即使失败，也不影响数据的一致性。

注意：无论是第二阶段提交还是第三阶段提交，其实都没有考虑事务提交阶段的失败情况，主要原因：1、基于之前的假设，日志是可靠的。2、对于网络的故障，即使丢失了提交命令，也可以根据相关的日志进行恢复，一般的分布式系统都会存在故障恢复的机制。

最后，二阶段提交和三阶段提交都只是分布式一致性算法的基础算法，不是一种完全可靠的算法（有理论证明：在分布式网络环境下，不存在完全可靠的算法来保证数据的一致性，这部分理论下次分享），但是，通常的实现都会对这些算法做一些容错处理，以保证在发生故障的时候能够恢复数据的一致性。