一，两阶段提交协议介绍
两阶段提交协议是用来保证分布式系统事务的协议。在分布式系统中，一个事务需要由多台机器协调完成，机器之间通过网络来通信，如何保证一组操作在多台机器上要么都做，要么都不做呢？（事务的ACID特性）
【比如，一个事务包括三个操作A,B,C，操作A,B,C分别 在机器1，2，3上完成，如果机器1成功提交了操作A，机器2成功提交了操作B，但是机器3执行操作C失败了，则需要撤消所有的操作……】
再扩展一下，把两阶段提交协议用到保证多个数据副本一致性的情景下，可以说：它是一种强一致性的中心化副本控制协议。比如，集群中的每个数据块都有三个副本，当修改某数据块时，为了保证一致性，这三个副本都需要修改。
强一致性体现在：当修改操作成功后，读取该副本时，一定能读到最新修改的数据。
中心化体现在：两阶段提交协议需要一个协调者来控制事务的流程。这个协调者可以视为中心控制节点。
副本控制协议：是指两阶段提交协议可用在保证副本一致性 情景中。
二，两阶段提交协议分析
在该协议中，节点分成两类：协调者和参与者。
两阶段提交协议流程主要分成两个阶段：当Client向协调者发起请求后，
阶段①：投票阶段
协调者询问所有的参与者是否可以执行提交操作
各个参与者为事务做准备，如分配资源、加锁……
参与者向协调者发送响应（可以提交 或者 不能提交）
这里需要注意的是：当参与者发送的响应是能提交事务，那它就不能放弃事务。因此，在一个参与者投票要求提交事务之前，它必须保证最终能够执行提交协议中它自己的那一部分，即使参与者出现故障，而被中途替换掉。为了保证能够提交，每个参与者必须将事务中所有发生改变的对象以及它自己的状态保存到持久性存储中。（如果某个参与者可以提交它那部分事务，那么它将把所有的更新和它的状态记录到持久存储中---也就是准备好提交）
阶段②：提交阶段
协调者收到所有的参与者返回的“可以提交”响应。向各个参与者发送“正式提交”命令
参与者各自在本地完成正式提交操作，成功后向协调者返回响应(“提交成功”或者“提交失败”）
当协调者收到所有的参与都“成功提交”的响应后，本次事务成功提交。否则失败（可能需要回滚或者重试）
三，两阶段提交协议的特点
①协议是阻塞的
协调者需要等待所有的参与者都返回响应后，才能继续下一步操作。
②网络容错能力差
只要有一个参与者失败了（网络超时或者宕机），协调者需要一直等待直到超时，本次事务失败。
③协调者单点故障
在第二阶段中，当协调者未发出“正式提交” 就宕机时，参与者将进入“未知”状态，完全不知道下一步该怎么办（重新发送第一阶段中的“可以提交”响应或者超时等待）
四，参考资料
本文转自hapjin博客园博客，原文链接:http://www.cnblogs.com/hapjin/p/5635993.html，如需转载请自行联系原作者
