三阶段提交学术资讯 - 科技工作者之家

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

简述两阶段提交协议（2PC）既简单又精巧，它把本地原子性提交行为的效果扩展到分布式事务，保证了分布式事务提交的原子性，并在不损坏日志的情况下，实现快速故障恢复，提高分布式数据库系统的可靠性。但是在最坏的情况下，两阶段提交协议在执行过程中可能出现任意多次服务器和通信故障。尽管协议不可能指定协议完成的时间限制，但它能够处理连续故障(服务器崩溃或消息丢失)，并保证最终完成。

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

2PC并不是一个无阻塞协议，有些失败修复方式有可能能使得站点阻塞。例如，一个进程在投了“提交”票之后，在接收到全局决策之前超时失败了；如果这个进程所能通信到的站点对全局决策同样一无所知，那么这个站点只好被阻塞了。实际上这种情况是相当少见的，但还是有必要引入一个更强的无阻塞协议——三段提交协议(3PC)。3PC协议在站点失败，甚至是所有的站点都失败的情况下也不会带来阻塞，但是会因为通信失败导致全局事务原子性被破坏，不同的站点收到了不同的策略。

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

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

两阶段提交协议（2PC）为了保持分布式事务的原子性，事务管理器使用了一个标准的两层恢复机制，称为两阶段提交协议(2PC)。这种两阶段提交协议可以确保事务的更新可以提交给所有参与的资源，或者确保更新完全回滚到所有的资源外，资源恢复到事务开始前的状态。通过这种方式，提交协议就可以保证数据的完整性。

两段提交协议把一个分布事务的所有分布管理分为两类：一个是协调者，所有其他的是参与者。协调者作出该事务是提交还是撤消的最后决定。所有的参与者负责管理相应的子事务的执行及各自局部数据库上执行写操作。

两段提交协议的内容是：

表决阶段：协调者向所有参与者发出“准备提交”信息。如果某个参与者准备提交，就回答就绪信息，否则回答撤消信息。参与者在回答前应把有关信息写入自己的日志中。协调者在发出准备提交信息前也要把有关信息写入自己的日志中。

如果在规定时间内协调者收到所有参与者的就绪信息，就作出提交的决定，否则作出撤消的决定。

执行阶段：协调者将有关决定的信息先写入日志，然后把这个决定发给所有的参与者。所有的参与者收到命令以后首先往自己的日志中写入收到提交(或撤消)决定的信息，并向协调者发送应答信息，最后执行有关决定。协调者收到所有参与者的应答信息后，一个事务执行到此结束。有关日志信息可以脱机保存。

采用两段提交协议以后，当系统发生故障时，各场地利用各自有关的日志信息(必要是加上后备副本)便可以执行恢复操作。2

三阶段提交协议内容3PC包括三段：决定段、准备提交段和执行段。其具体过程如图1所示。