二阶段协议提交和三阶段协议提交

背景

前文讲到分布式理论CAP原则，满足分区容错性的同时要解决数据的最终一致性，也就是说分布式节点数据或状态在某一时刻要达到最终一致。

分布式系统中的节点通信存在两种模型：共享内存（Shared memory）和消息传递（Messages passing）。

基于消息传递通信模型的分布式系统，不可避免的会发生以下错误：进程可能会慢、被杀死或者重启，消息可能会延迟、丢失、重复、节点间网络可能会故障，为达到数据的最终一致，前人经过不断的优化设计了两段阶段协议提交和三阶段协议提交算法，以及业界公认的分布式一致性算法：Paxos算法，本文主要讲两阶段协议提交和三阶段协议提交算法，以此为背景在后续的章节将讲到Paxos算法。

XA

业界的数据库厂商都遵循公开的数据库事务标准协议。XA协议由Tuxedo首先提出的，并交给X/Open组织（X/Open国际联盟有限公司是一个欧洲基金会，它的建立是为了向UNIX环境提供标准），作为资源管理器（数据库）与事务管理器的接口标准。目前，Oracle、Informix、DB2和Sybase等各大数据库厂家都提供对XA的支持。XA协议采用两阶段提交方式来管理分布式事务。XA接口提供资源管理器与事务管理器之间进行通信的标准接口。XA协议包括两套函数，以xa_开头的及以ax_开头的。

分布式事务

为了实现分布式事务，需要使用下面将介绍的两阶段提交协议。

阶段一：开始向事务涉及到的全部资源发送提交前信息。此时，事务涉及到的资源还有最后一次机会来异常结束事务。如果任意一个资源决定异常结束事务，则整个事务取消，不会进行资源的更新。否则，事务将正常执行，除非发生灾难性的失败。为了防止会发生灾难性的失败，所有资源的更新都会写入到日志中。这些日志是永久性的，因此，这些日志会幸免于难并且在失败之后可以重新对所有资源进行更新。

阶段二：只在阶段一没有异常结束的时候才会发生。此时，所有能被定位和单独控制的资源管理器都将开始执行真正的数据更新。 在分布式事务两阶段提交协议中，有一个主事务管理器负责充当分布式事务协调器的角色。事务协调器负责整个事务并使之与网络中的其他事务管理器协同工作。 为了实现分布式事务，必须使用一种协议在分布式事务的各个参与者之间传递事务上下文信息。这就要求不同开发商开发的事务参与者必须支持一种标准协议，才能实现分布式的事务（IIOP便是这种协议）。

二阶段提交协议

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

两阶段提交简化为：第一阶段：提交请求阶段（或投票阶段），第二阶段：提交执行阶段，如下图：

第一阶段，提交请求阶段：

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

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

第二阶段，提交执行阶段：当协调者节点从所有参与者节点获得的相应消息都为"同意"时：

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

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

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

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

缺点

1. 阻塞：二阶段提交算法的最大缺点就在于它的执行过程中间，节点都处于阻塞状态。即节点之间在等待对方的相应消息时，它将什么也做不了。特别是，当一个节点在已经占有了某项资源的情况下，为了等待其他节点的响应消息而陷入阻塞状态时，当第三个节点尝试访问该节点占有的资源时，这个节点也将连带陷入阻塞状态，例如，一个进程在投了“提交”票之后，在接收到全局决策之前超时失败了；如果这个进程所能通信到的站点对全局决策同样一无所知，那么这个站点只好被阻塞了；
2. 保守：协调者节点指示参与者节点进行提交等操作时，如有参与者节点出现了崩溃等情况而导致协调者始终无法获取所有参与者的响应信息，这时协调者将只能依赖协调者自身的超时机制来生效。但往往超时机制生效时，协调者都会指示参与者进行回滚操作。这样的策略显得比较保守，例如：参与由于网络故障没有响应“提交”请求时，协调者会通过超时机制指示参与者回滚，例如：协调者发送了“提交”消息后宕机，而此时接收“提交”的参与者也宕机了，此时，即使产生了新的协调者也无法知道该事务的执行情况，因此，只能选择回滚。

其中，保守也包括了单点故障，一旦参与由于网络原因或者节点异常导致无法响应，则整个请求面临回滚。采用两段提交协议以后，当系统发生故障时，各节点利用各自有关的日志信息(必要是加上后备副本)便可以执行恢复操作。两阶段提交协议最大的问题在于可能造成参与者很长时间停留在不确定状态上。

三阶段提交协议

三阶段提交，也叫三阶段提交协议，是在计算机网络及数据库的范畴下，使得一个分布式系统内的所有节点能够执行事务的提交的一种分布式算法。三阶段提交是为解决两阶段提交协议的缺点而设计的。

对于前面提到的超时问题，两阶段提交协议可能造成参与者很长时间停留在不确定状态上。这些延迟主要源于协调者故障或者不能从参与者那里得到getDecision请求的回答。即使协作协议允许参与者可以向其他参与者发送getDecision请求，但是当所有参与者都处于不确定状态时，延迟仍然不可避免。

三阶段提交协议(3PC)在恢复过程中协调者发生故障的情况下，也能够避免事务阻塞。这种方法的基本思想是在协调者发出prepare消息并收到所有参与者的yes消息时，向所有参与者发送precommit消息，而不是commit消息。然后在收到足够数目(比必须处理的最大故障数目要大)的ack消息以后，协调者向日志中强迫写入commit记录，再向所有参与者发送commit消息。在3PC中，协调者能够有效地推迟commit决定，只有在确定所有下属都知道commit决定以后，才真正发出commit决定。如果协调者随后发生了故障，在协调者恢复之前，参与者之间就可以互相通信，确定事务是应该提交还是中止事务(如果所有参与者都没有收到precommit消息)。如下图：

第一阶段：决定阶段

1. 协调者向所有参与者发出准备消息(prepare)(同2PC)；
2. 若任一参与者回答中止Abort消息，则进入第三段(执行段)，协调者发出反转Rollback命令。

若所有参与者都回答Vote-Commit消息，则进入第二段(准备提交段)。

第二阶段：准备提交段

1. 由协调者发准备提交消息(Prepare to Commit)；
2. 参与者收到该消息后写入运行记录(Log record)中，并回答确认消息ACK。

第三阶段：执行阶段

1. 协调者根据参与者回答的ACK/Abort消息，向参与者发Commit/Rollback命令；
2. 参与者根据协调者的命令决定执行提交或回滚，完成事务的处理。

三阶段提交将二阶段提交的准备阶段分为投票阶段和准备阶段，一旦投票通过，将执行提交，否则执行回滚。避免了事务占用资源，同时，只要收到足够多的参与者同意提交，那么即使在第三阶段发生异常也可以通过参与者之间互相通信来保障数据的一致性。

三阶段提交协议在正常执行时会增加许多额外的负载，并且为了确保不发生事务阻塞，还需要在发生传输故障时不会发生网络分割(部分参与者不能同其他参与者相连)。出于这些原因，3PC并没有实际应用。

无论是二阶段提交还是三阶段提交都有其局限性，后面我们将讲到Paxos算法。Google Chubby的作者Mike Burrows说过，世上只有一种一致性算法，那就是Paxos，所有其他一致性算法都是Paxos算法的不完整版。

二阶段提交参考链接：https://baike.baidu.com/item/%E4%BA%8C%E9%98%B6%E6%AE%B5%E6%8F%90%E4%BA%A4/15735523?fr=aladdin

三阶段提交参考链接：https://baike.baidu.com/item/%E4%B8%89%E9%98%B6%E6%AE%B5%E6%8F%90%E4%BA%A4/15978718?fr=aladdin

分布式事务参考链接:https://baike.baidu.com/item/%E5%88%86%E5%B8%83%E5%BC%8F%E4%BA%8B%E5%8A%A1/4747029