https://blog.csdn.net/nirendao/article/details/85168399
 
前面几篇博客中提到了CAP原理，以及CAP的几种组合，比如符合AP的有Gossip协议；符合CP的有Paxos协议；符合CA的有二阶段提交(2PC). 这篇文章就来介绍下二阶段提交和有所改进的三阶段提交。
 
二阶段提交(2PC)
 为了使分布式系统架构下所有节点在进行事务提交时保持一致性而设计的一种算法。在分布式系统中，每个节点虽然可以知晓自己的操作时成功或者失败，却无法知道其他节点的操作的成功或失败。当一个事务跨越多个节点时，为了保持事务的ACID特性，需要引入一个作为协调者的组件来统一掌控所有节点(称作参与者)的操作结果，并最终指示这些节点是否要把操作结果进行真正的提交(比如将更新后的数据写入磁盘等等)。因此，二阶段提交的算法思路可以概括为：参与者将操作成败通知协调者，再由协调者根据所有参与者的反馈决定各参与者是否要提交操作还是中止操作。
 
第一阶段：准备阶段
 第二阶段：提交阶段
 
第一阶段：准备阶段
 事务协调者(事务管理器)给每个参与者(资源管理器)发送Prepare消息，每个参与者要么直接返回失败(如权限验证失败)，要么在本地执行事务，但不提交，达到一种“万事俱备，只欠东风”的状态。
 
具体分为3个步骤：
 1.1 协调者询问所有参与者是否可以执行提交操作(vote)，并等待各参与者的响应。
 1.2 参与者执行事务操作，但没有提交（即没有commit）
 1.3 各参与者响应协调者的询问。如果参与者的事务操作执行成功，则返回”同意”；如果参与者的事务操作执行失败，则返回”中止”。
 
第二阶段：提交阶段
 如果协调者收到了任一参与者的失败消息或者超时，则给每个参与者发送回滚(Rollback)消息；否则，发送提交(Commit)消息。
 参与者根据协调者的指令执行提交或回滚操作，释放所有事务处理过程中使用的锁资源。(注意:必须在最后阶段释放锁资源)
 
两阶段提交(2PC)的几个缺点
 同步阻塞问题
 执行过程中，所有参与者节点都是事务阻塞型的。当参与者占有公共资源时，其他第三方节点访问公共资源不得不处于阻塞状态。
 
单点故障
 由于协调者的重要性，一旦协调者发生故障。参与者会一直阻塞下去。尤其在第二阶段，协调者发生故障，那么所有的参与者还都处于锁定事务资源的状态中，而无法继续完成事务操作。（如果是协调者挂掉，可以重新选举一个协调者，但是无法解决因为协调者宕机导致的参与者处于阻塞状态的问题）
 
数据不一致
 在阶段二，当协调者向参与者发送commit请求之后，发生了网络异常，这将导致只有部分参与者收到了commit请求。这部分参与者接到commit请求之后就会执行commit操作，但是其他未接到commit请求的参与者则无法执行事务提交，于是整个分布式系统便出现了数据不一致的问题。
 
二阶段无法解决的问题
 协调者在发出commit消息之后宕机，而唯一接收到这条消息的参与者同时也宕机了。那么即使协调者通过选举协议产生了新的协调者，这条事务的状态也是不确定的，没人知道事务是否被已经提交。
 
三阶段提交
 由于二阶段提交存在以上诸多问题，所以研究者们在二阶段提交的基础上做了改进，提出了三阶段提交。
 
三阶段提交有2个改动：
 
在协调者和参与者中都引入了超时机制。
 在第一阶段和第二阶段中插入一个准备阶段。保证了在最后提交阶段之前各参与节点的状态是一致的。
 三阶段提交分为三个阶段： CanCommit、PreCommit、DoCommit
 
1. CanCommit阶段
 协调者向参与者发送commit请求，参与者如果可以提交就返回Yes，否则返回No.
 
事务询问
 协调者向参与者发送CanCommit请求，询问是否可以执行事务提交操作，并进入等待
 
响应反馈
 参与者接到CanCommit请求之后，如果认为可以顺利执行事务，则返回Yes，并进入预备状态；否则反馈No
 
2. PreCommit阶段
 协调者根据参与者的响应来决定是否可以继续事务的PreCommit操作。根据响应情况，有以下2种可能： 事务预执行 或 中断事务
 
2.1 假如协调者从所有的参与者获得的反馈都是Yes响应，那么就会执行事务的预执行。
 
发送预提交请求
 协调者向参与者发送PreCommit请求，并进入Prepared阶段。
 
事务预执行
 参与者接收到PreCommit请求后，会执行事务操作
 
响应反馈
 如果参与者成功执行了事务操作，则返回ACK响应，同时开始等待最终指令。
 
2.2 假如有任何一个参与者向协调者发送了No响应或等待超时,那么就执行事务的中断
 
发送中断请求
 协调者向所有参与者发送abort请求。
 
中断事务
 参与者收到来自协调者的abort请求之后（或超时之后，仍未收到协调者的请求），执行事务的中断。
 
3. DoCommit阶段
 该阶段进行真正的事务提交，也可以分为以下两种情况: 执行提交 或 中断事务
 
3.1 执行提交
 
发送提交请求
 协调者接收到参与者发送的ACK响应，那么它将从预提交状态进入到提交状态。并向所有参与者发送DoCommit请求。
 
事务提交
 参与者接收到DoCommit请求之后，执行正式的事务提交；并在完成事务提交之后释放所有事务资源。
 
响应反馈
 事务提交完之后，向协调者发送Ack响应。
 
完成事务
 协调者接收到所有参与者的Ack响应之后，完成事务。
 
3.2 中断事务
 协调者没有接收到参与者发送的ACK响应（不是ACK或超时），那么就执行中断事务。
 
1.发送中断请求
 协调者向所有参与者发送abort请求
 
2.事务回滚
 参与者接收到abort请求之后，利用其在阶段二记录的undo信息来执行事务的回滚操作，并在完成回滚之后释放所有的事务资源。
 
3.反馈结果
 参与者完成事务回滚之后，向协调者发送ACK消息
 
4.中断事务
 协调者接收到参与者反馈的ACK消息之后，执行事务的中断。
 
在DoCommit阶段，如果参与者无法及时接收到来自协调者的DoCommit或者abort请求，则在等待超时之后，会继续进行事务的提交。
 
2PC与3PC的区别
 相对于2PC，3PC主要解决单点故障问题，并减少阻塞（一旦参与者无法及时收到来自协调者的信息之后，他会默认执行commit，而不会一直持有事务资源并处于阻塞状态）。
 但是3PC也有数据一致性问题: 比如，由于网络原因，协调者发送的abort响应没有及时被参与者接收到，那么参与者在等待超时之后执行了commit操作，这样就和其他接到abort命令并执行回滚的参与者之间存在数据不一致了。
 
（完）

原文地址：http://blog.csdn.net/lidatgb/article/details/38468073
 
 
     因为事务需要实现ACID，即原子性、一致性、隔离性、持久性，所以需要采用一定的机制来保证，通常采用的是分阶段提交的方式。
 
     XA:XA协议，规定事务管理器和资源管理器接口，采用二阶段提交协议。
 
一阶段提交协议
 
     一阶段提交协议相对简单，如下图：
 
     
 
     当然，前提是开启了事务，然后在应用程序发出提交/回滚请求后，数据库执行操作，而后将成功/失败返回给应用程序，程序继续执行。
 
     一阶段提交协议相对简单，简单带来的优点就是，它不用再与其他的对象交互，节省了判断步骤和时间，所以在性能上是在阶段提交协议中最好的。
 
二阶段提交协议
 
     一阶段提交协议有其优点，但缺点也很明显：
 
 
 
数据库确认执行事务的时间较长，出问题的可能性就随之增大。
如果有多个数据源，一阶段提交协议无法协调他们之间的关系。
 
 
 
    所以在一阶段协议的基础上，有了二阶段协议，二阶段协议的好处是添加了一个管理者角色，如下：
 
     
 
 
     很明显，二阶段协议通过将两层变为三层，增加了中间的管理者角色，从而协调多个数据源之间的关系，二阶段提交协议分为两个阶段。
 
    第一阶段
 
     
 
 
     应用程序调用了事务管理器的提交方法，此后第一阶段分为两个步骤：
 
 
 
事务管理器通知参与该事务的各个资源管理器，通知他们开始准备事务。
资源管理器接收到消息后开始准备阶段，写好事务日志并执行事务，但不提交，然后将是否就绪的消息返回给事务管理器（此时已经将事务的大部分事情做完，以后的内容耗时极小）。
 
 
 
    第二阶段
 
     
 
 
     第二阶段也分为两个步骤：    
 
 
 
事务管理器在接受各个消息后，开始分析，如果有任意其一失败，则发送回滚命令，否则发送提交命令。
各个资源管理器接收到命令后，执行（耗时很少），并将提交消息返回给事务管理器。
 

     事务管理器接受消息后，事务结束，应用程序继续执行。
 

     为什么要分两步执行？一是因为分两步，就有了事务管理器统一管理的机会；二尽可能晚地提交事务，让事务在提交前尽可能地完成所有能完成的工作，这样，最后的提交阶段将是耗时极短，耗时极短意味着操作失败的可能性也就降低。
 
 

     
 同时，二阶段提交协议为了保证事务的一致性，不管是事务管理器还是各个资源管理器，每执行一步操作，都会记录日志，为出现故障后的恢复准备依据。
 

     二阶段提交协议的存在的弊端是阻塞，因为事务管理器要收集各个资源管理器的响应消息，如果其中一个或多个一直不返回消息，则事务管理器一直等待，应用程序也被阻塞，甚至可能永久阻塞。
 
事务与协议
 

     那么本地事务和分布式事务，分别采用的是哪些协议？我在
 RedBooks的一个文档中看到的是：
 

 Global transactions
 
 
 

     Although the XAResource interface is intended to support two phase commit, the specification does not force an adapter to support two phase commit. However, if the resource adapter does implement XAResource it must also implement support for one phase commit. This allows the transaction manager to do one phase commit optimization (explained later) by setting the onePhase flag to true when doing acommit.……
 
 
 

 Local transactions
 
 
 

     A local transaction is managed by the resource manager without the need for an external transaction manager, and can be utilized when only one resource is involved. Local transactions only support one phase commit, because they only reference one EIS.……
 
 
 

     大意是：虽然实现XA接口的目的是为了支持二阶段提交协议，但是它也支持一阶段提交协议。本地事务只支持一阶段提交；分布式事务默认采用的是二阶段提交，如果在分布式事务中非得使用一阶段提交协议，那么只要数据源多余一个就会抛出异常，如果只有一个数据源则正确执行。
 
总结
 

     一阶段提交协议和二阶段提交协议只是比较常用的两个，此外还有其他协议，可自行研究。

一、二阶段提交算法的描述：
 
 
 二阶段提交算法的成立基于以下假设：
 
该分布式系统中，存在一个节点作为协调者(Coordinator)，其他节点作为参与者(Cohorts)。且节点之间可以进行网络通信。
所有节点都采用预写式日志，且日志被写入后即被保持在可靠的存储设备上，即使节点损坏不会导致日志数据的消失。
所有节点不会永久性损坏，即使损坏后仍然可以恢复。
 
 以下对二阶段提交算法分阶段进行说明。
 
 第一阶段(提交请求阶段)
 
协调者节点向所有参与者节点询问是否可以执行提交操作，并开始等待各参与者节点的响应。
参与者节点执行询问发起为止的所有事务操作，并将Undo信息和Redo信息写入日志。
各参与者节点响应协调者节点发起的询问。如果参与者节点的事务操作实际执行成功，则它返回一个"同意"消息；如果参与者节点的事务操作实际执行失败，则它返回一个"中止"消息。
 
 有时候，第一阶段也被称作投票阶段，即各参与者投票是否要继续接下来的提交操作。
 
 第二阶段(提交执行阶段)
 
 成功
 
 当协调者节点从所有参与者节点获得的相应消息都为"同意"时：
 
协调者节点向所有参与者节点发出"正式提交"的请求。
参与者节点正式完成操作，并释放在整个事务期间内占用的资源。
参与者节点向协调者节点发送"完成"消息。
协调者节点受到所有参与者节点反馈的"完成"消息后，完成事务。
 
 失败
 
 如果任一参与者节点在第一阶段返回的响应消息为"中止"，或者 协调者节点在第一阶段的询问超时之前无法获取所有参与者节点的响应消息时：
 
协调者节点向所有参与者节点发出"回滚操作"的请求。
参与者节点利用之前写入的Undo信息执行回滚，并释放在整个事务期间内占用的资源。
参与者节点向协调者节点发送"回滚完成"消息。
协调者节点受到所有参与者节点反馈的"回滚完成"消息后，取消事务。
 
 有时候，第二阶段也被称作完成阶段，因为无论结果怎样，协调者都必须在此阶段结束当前事务
 以上的内容均来自于维基百科，可以参见：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、对于网络的故障，即使丢失了提交命令，也可以根据相关的日志进行恢复，一般的分布式系统都会存在故障恢复的机制。
 

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

 

分布式系统，这早已不是什么新鲜的东西了，在分布式系统的架构设计过程中，往往会存在分布式一致性的问题，经过前人的辛苦探究，提出了二阶段提交协议，三阶段提交协议，Paxos算法等等，用来解决分布式一致性的问题。今天我就讲一下，二阶段提交协议和三阶段提交协议的过程，以及它们的优缺点。
 
2PC，就是二阶段提交协议。顾名思义，就是将事务的提交过程分成两个阶段来处理。那我们来看看这两个阶段分别做了什么。
 
阶段一：
 
   1.提交事务请求：
 
      协调者向所有的参与者发送事务内容，询问是否可以执行事务提交操作，并开始等待各参与者的响应。
 
   2.执行事务：
 
      各个参与者节点执行事务操作。并将Undo和Redo信息记入事务日志中。
 
   3.各参与者向协调者反馈事务询问的响应：
 
      如果参与者成功执行了事务操作，那么就反馈给协调者Yes响应，表示事务可以执行；如果参与者没有成功执行事务，那么就反馈给协调者No响应，表示事务不可以执行。
 
阶段二：
 
   1.执行事务提交：
 
      假如协调者从所有参与者获得的响应都为Yes，那么就执行事务提交，协调者向所有参与者节点发出Commit请求。
 
   2.参与者提交事务：  
 
      参与者接收到Commit请求后，会正式执行事务提交操作，并在完成提交之后释放在整个事务执行期间占用的事务资源,并向协调者发送Ack消息。
 
   3.完成事务：
 
      协调者接收到所有参与者反馈的Ack消息后，完成事务。
 
这里我画了一张时序图，来说明其中的过程，如图所示：
 
 
 
 
中断事务
 
假如任何一个参与者反馈给协调者No响应，或者在等待超时之后，协调者没有收到所有参与者的响应，那么就会中断事务。
 
   1.发送回滚请求
 
      协调者向所有参与者发送Rollback请求。
 
   2.事务回滚
 
     参与者接收到Rollback请求后，会利用其在阶段一中记录的Undo信息来执行事务回滚操作，完成回滚之后释放在整个事务执行期间占用的资源，并向协调者发送Ack消息，协调者接收到所有的参与者反馈的Ack消息后，完成事务中断。
 
中断的过程就是这样，下面一张时序图，描述中断事务的过程。
 
 
二阶段提交协议的整个过程就是这样，这种先请求后提交的方式，能够保证所有节点在进行事务处理过程中保持原子性，进行统一的提交或回滚，可以看作是一个强一致性的算法。那我们就来思考一下，它有哪些优点，以及会带来什么问题。
 
优点：简单好用，实现方便。
 
缺点：同步阻塞，单点问题，还是会有数据不一致的情况出现。
 
同步阻塞：在二阶段提交事务的过程中，所有参与该事务操作的逻辑都处于阻塞状态，各个参与者在等待其他参与者的响应过程中，无法做其他的操作。
 
单点问题：在二阶段提交协议中，协调者这个角色是很重要的，一旦协调者挂掉，将导致整个提交流程无法运转，若是在第二阶段协调者挂掉，参与者将一直处于锁定事务资源的状态，无法继续完成事务操作。
 
数据不一致：若是在第二阶段，协调者在向所有参与者发送commit请求时，由于局部网络的故障，只有部分参与者受到commit请求，提交事务，这样没有受到commit请求的就没有提交事务，出现了数据不一致的情况。
 
3PC,就是三阶段提交协议，顾名思义，就是把事务的提交过程分为三个阶段，实际上它就是在原来二阶段提交上做了一部分改进，那我们就来看看它的过程，以及它到底改进了什么。
 
阶段一：CanCommit
 
     事务询问：
 
     协调者向所有的参与者发送一个包含事务内容的canCommit请求，询问是否可以执行事务提交操作，并开始等待各个参与者的响应。参与者接收请求后，正常情况下，如果认为其自身可以顺利执行事务，那么会反馈Yes响应，并进入预备状态，否则反馈No响应。
 
阶段二：PreCommit
 
在阶段二，协调者根据各参与者的反馈情况来决定是否可以进行事务的PreCommit操作，正常情况下，包含两种可能。一种是参与者全部反馈Yes响应，则进入预提交阶段，另一种时有参与者反馈No响应或者等待超时后，没有收到全部的反馈响应，则会中断事务，我们来分别看一下这两种情况。
 
第一种：预提交：
 
   协调者向所有的参与者发送PreCommit请求，并进入Prepared阶段。
 
   参与者接收到preCommit的请求，执行事务操作，并将Undo和Redo信息记录到事务日志中，然后向协调者反馈Ack响应，等待最终的指令提交或中止。
 
第二种：中断事务：
 
   协调者向所有的参与者发出abort请求，参与者无论是收到协调者的abort请求，还是等待请求过程中超时，参与者都会中断事务。
 
阶段三：doCommit
 
这一阶段，即将开始真正的事务提交，同样也会存在两种可能的情况。
 
第一种：执行提交：
 
   1.发送提交请求：
 
      进入这一阶段：假如协调者处于正常的工作状态，并且它接收到了来自所有参与者的Ack响应，那么它将从预提交状态转换到提交状态，并向所有的参与者发送doCommit请求。
 
   2.事务提交：
 
     参与者接收到doCommit请求后，会正式执行事务提交操作，并在完成提交之后释放在整个事务执行期间占用的事务资源，并向协调者发送Ack消息。协调者接收到所有参与者反馈的Ack消息后，完成事务。
 
第二种：中断事务：
 
   进入这一阶段，假设协调者处于正常状态（这个很关键），并且有任意一个参与者向协调者反馈了No响应，或者等待超时之后，协调者无法接收到所有参与者的反馈响应。那么就会中断事务。
 
   协调者向所有参与者节点发送abort请求。
 
   各个参与者接收到abort请求后，会利用其在阶段二中记录的Undo信息来执行事务回滚操作，并在完成回滚之后释放在整个事务执行期间占用的资源，并向参与者发送Ack消息。协调者接收到所有参与者反馈的Ack消息后，中断事务。
 
一旦进入到阶段三，可能会存在两种故障：1.协调者出现问题；2.协调者和参与者之间的网络出现故障。
 
无论出现哪种情况，最终都会导致参与者无法及时接收到来自协调者doCommit或是abort请求，针对这样的异常情况，参与者都会在等待超时之后，继续提交事务操作。
 
到这里三阶段提交协议就讲完了，相比较于二阶段提交协议，它降低了参与者的阻塞范围，并在出现单点故障后，继续达成一致。同样三阶段提交协议也会带来数据不一致的问题，在第二阶段，协调者向所有参与者发送preCommit请求时，如果这时网络出现问题，协调者无法和参与者进行正常通信，参与者此时仍然会提交事务，而协调者等待超时后，进行事务中断，这样就会带来数据不一致的情况。
 
总结：二阶段提交协议和三阶段提交协议都是解决分布式数据一致性问题的优秀算法，尽管从根本上并不能保证绝对的一致性，但也并不影响它们在实际工程上的使用。有句话是这么说的，在存在消息丢失的不可靠信道上试图通过消息传递的方式达到一致性是不可能的,有兴趣的朋友可以研究一下paxos算法以及它的证明过程。