两阶段提交协议

　　集中式与分布式事务的另一个重要的不同点在于它们各自所需关注的错误的属性上。在集中式系统中，错误都是要么不错要么全错(all-or-nothing)，也就是说要么系统正常工作事务正常处理，要么系统出错不会有任何事务完成。但是在分布式系统中，可能出现部分失败(partial failures)的情况，某些节点正常工作但是其他一些节点出错了。

　　这种局部失败的情况正是造成分布式系统中很多难解的问题的根源。在事务处理中就有这样的一个难解问题，即分布式事务的一致性问题。比如T就可能在某些节点上进行了Commit，而在某些节点上进行了Abort，这样就产生了不一致。

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

2PC的两个阶段是指投票阶段和决定阶段：
第一阶段(提交请求阶段/投票阶段)
　　协调者节点向所有参与者节点询问是否可以执行提交操作，并开始等待各参与者节点的响应。
　　参与者节点执行询问发起为止的所有事务操作，并将Undo信息和Redo信息写入日志。
　　各参与者节点响应协调者节点发起的询问。如果参与者节点的事务操作实际执行成功，则它返回一个”同意”消息；如果参与者节点的事务操作实际执行失败，则它返回一个”中止”消息。
　　简单地说，就是各参与者投票是否要继续接下来的提交操作。

第二阶段(提交执行阶段/决定阶段)：
　　1）成功
　　当协调者节点从所有参与者节点获得的相应消息都为”同意”时：
　　协调者节点向所有参与者节点发出”正式提交”的请求。
　　参与者节点正式完成操作，并释放在整个事务期间内占用的资源。
　　参与者节点向协调者节点发送”完成”消息。
　　协调者节点受到所有参与者节点反馈的”完成”消息后，完成事务。
　　2）失败
　　如果任一参与者节点在第一阶段返回的响应消息为”终止”，或者协调者节点在第一阶段的询问超时之前无法获取所有参与者节点的响应消息时：
　　协调者节点向所有参与者节点发出”回滚操作”的请求。
　　参与者节点利用之前写入的Undo信息执行回滚，并释放在整个事务期间内占用的资源。
　　参与者节点向协调者节点发送”回滚完成”消息。
　　协调者节点受到所有参与者节点反馈的”回滚完成”消息后，取消事务。

　　请注意，在失败情况下有一种情况为超时，因为消息可能会由于故障而无法到达。因此，进程可能会无限等待下去。为避免这个问题，需要使用超时机制。
　　 还是来举个现实生活中的例子吧：
　　 你是个大吃货，发现了聚餐的好地方，想叫上好基友们去尝鲜。于是，你给他们群发短信：“各位亲，我发了个好地儿，现在出来聚聚吧，地址是XXXXXX”，收到信息的小伙伴们，就寻路过去了，边走边记回去的路（写日志），到了的发短信给你“我到啦”，还有找了半天没找地的小伙伴发短信给你“我没找到地，就不去啦”（投票阶段）
　　 你如果收到所有小伙伴到了的信息，又发信息给他们“我订了紫兰厅，你们去吧”，小伙伴们把车停好（释放资源），来到紫兰厅，又给你发信息“我来啦”，你看大家到齐了，乖乖点菜去了。
　　 如果，你收到了有人不能来的短信，或者有人一个小时都没回短信（关机或者电信故障什么的），你决定取消这次聚餐，发短信给大家说“小伙伴们，有人不能来啦，你们回去吧”。于是，大家顺着记的路回家了（回滚），回到家后，把车停好（释放资源），发短信给你“我到啦”，你收到大家的短信，恩，你可以睡觉去了。

总结：
　　2PC是分布式情况下强一致性算法
　
　　协调者发生故障。协调者需要将事务相关信息记录到操作日志并同步到备用协调者，假如协调者发生故障，备用协调者可以接替它完成后续的工作。如果没有备用协调者，协调者又发生了永久性故障，事务参与者将无法完成事务而一直等待下去。

　　该算法吞吐量较低，两阶段提交协议是阻塞协议，执行过程中需要锁住其他更新，且不能容错，大多数分布式存储系统都采用敬而远之的做法，放弃对分布式事务的支持。