两阶段提交协议

一、事务

事务处理的困难源于两个方面：concurrency和failures。为了达到高的性能，并发是必要的。而在现实中，计算机系统会面临各种各样的故障，操作系统可能会出错，硬件也有可能会出错。当这些错误发生时，应用程序可能会在正执行的过程中被打断，而这可能会产生错误的结果。比如用户正在转账，在中间失败可能会导致一个账户上的钱少了，但是另一个账户却没有收到钱的情况。Recovery就是要避免因故障而产生错误结果。所以就引出了Concurrency Control和Recovery这两个概念。

对于一个解决了并发控制和恢复问题的系统来说，在用户看来，所有程序的执行都是原子的(看起来就好像没有其他程序在并行执行)，可靠的(看起来好像并没有故障发生)。这种原子的可靠的程序执行过程就称之为事务。并发控制算法用来保证事务原子性地执行。

二、两阶段提交协议

维基百科的解释：

为了使基于分布式系统架构下的所有节点在进行事务提交时保持一致性而设计的一种算法。通常，二阶段提交也被称为是一种协议(Protocol)。在分布式系统中，每个节点虽然可以知晓自己的操作时成功或者失败，却无法知道其他节点的操作的成功或失败。当一个事务跨越多个节点时，为了保持事务的[ACID]特性，需要引入一个作为协调者的组件来统一掌控所有节点(称作参与者)的操作结果并最终指示这些节点是否要把操作结果进行真正的提交(比如将更新后的数据写入磁盘等等)。因此，二阶段提交的算法思路可以概括为： 参与者将操作成败通知协调者，再由协调者根据所有参与者的反馈情报决定各参与者是否要提交操作还是中止操作。

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

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

　　第一阶段（投票阶段）：

1）协调者节点向所有参与者节点询问是否可以执行提交操作(vote)，并开始等待各参与者节点的响应。

2）参与者节点执行询问发起为止的所有事务操作，并将Undo信息和Redo信息写入日志。（注意：若成功这里其实每个参与者已经执行了事务操作）

3）各参与者节点响应协调者节点发起的询问。如果参与者节点的事务操作实际执行成功，则它返回一个"同意"消息；如果参与者节点的事务操作实际执行失败，则它返回一个"中止"消息。

　　第二阶段（提交执行阶段）：

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

1）协调者节点向所有参与者节点发出"正式提交(commit)"的请求。

2）参与者节点正式完成操作，并释放在整个事务期间内占用的资源。

3）参与者节点向协调者节点发送"完成"消息。

4）协调者节点受到所有参与者节点反馈的"完成"消息后，完成事务。

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

1）协调者节点向所有参与者节点发出"回滚操作(rollback)"的请求。

2）参与者节点利用之前写入的Undo信息执行回滚，并释放在整个事务期间内占用的资源。

3）参与者节点向协调者节点发送"回滚完成"消息。

4）协调者节点受到所有参与者节点反馈的"回滚完成"消息后，取消事务。

　　不管最后结果如何，第二阶段都会结束当前事务。


二阶段提交缺点：

　　1、执行过程中，所有参与节点都是事务阻塞型的。当参与者占有公共资源时，其他第三方节点访问公共资源不得不处于阻塞状态。

　　2、参与者发生故障。协调者需要给每个参与者额外指定超时机制，超时后整个事务失败。（没有多少容错机制）

　　3、协调者发生故障。参与者会一直阻塞下去。需要额外的备机进行容错。

　　4、二阶段无法解决的问题：协调者再发出commit消息之后宕机，而唯一接收到这条消息的参与者同时也宕机了。那么即使协调者通过选举协议产

生了新的协调者，这条事务的状态也是不确定的，没人知道事务是否被已经提交。

参考文章：http://blog.jobbole.com/95632/

https://zh.wikipedia.org/wiki/%E4%BA%8C%E9%98%B6%E6%AE%B5%E6%8F%90%E4%BA%A4