首页 理论教育三阶段提交协议在分布式数据库技术中的应用

三阶段提交协议在分布式数据库技术中的应用

【摘要】:三阶段提交协议是为无阻塞协议而设计的。因此有必要对2PC协议进行修改。因为从INITIAL状态到COMMIT状态间有三个状态转换,所以我们称为三阶段提交协议。图10.173PC协议的状态转换图1.终止协议下面分析3PC协议每个状态在超时时的情况。协调者单边决定夭折该事务。因此它将abort记录写入日志,并发送″global-abort″消息给所有已经选择提交事务的参与者。3PC协议如图10.18所示。参与者可能处于INITIAL、READY、ABORT、PRECOMMIT状态。因此协调者将全局提交该事务,发送″global-commit″消息。

三阶段提交(3PC)协议是为无阻塞协议而设计的。

设计无阻塞原子提交协议的必要和充分条件是什么?它可以简述为:提交协议在状态转换时是同步的,当且仅当其对应的转换图不包含如下内容。

●没有一个状态同时与COMMIT和ABORT状态为邻。

●没有一个不可提交状态与COMMIT状态为邻。

相邻是指一次转化就能到达相邻状态。

我们观察2PC协议中的COMMIT状态(见图10.13)。如果任意一个进程进入这个状态,意味着所有节点都选举了提交,这个状态称为可提交的(committable)。2PC协议中的其他状态称为不可提交状态(noncommittable)。现在我们考察READY状态,这不是一个可提交的状态。

显然,当协调者处于WAIT状态和参与者处于READY状态时,2PC协议会破坏非阻塞条件。因此有必要对2PC协议进行修改。

我们将在WAIT(READY)和COMMIT状态之间增加一个状态作为缓冲状态,即准备提交(PRECOMMIT)状态(如果最后决策是提交)。3PC协议的状态转换图如图10.17所示。因为从INITIAL状态到COMMIT状态间有三个状态转换,所以我们称为三阶段提交(3PC)协议。除PRECOMMIT状态外,其他情况与图10.13所示的情况相同。3PC也是一个所有状态都在一个状态转换中同步的协议。所以2PC的非阻塞先决条件也适用于3PC协议。

图10.17 3PC协议的状态转换图

1.终止协议

下面分析3PC协议每个状态在超时时的情况。

1)协调者超时

3PC时,协调者在WAIT、PRECOMMIT、COMMIT或ABORT四种状态下会发生超时。

在WAIT状态下超时:此时的情况与2PC时协调者超时的情况相同。协调者单边决定夭折该事务。因此它将abort记录写入日志,并发送″global-abort″消息给所有已经选择提交事务的参与者。

在PRECOMMIT状态时超时:此时协调者不知道相应的参与者是否已经转入PRECOMMIT状态。然而,协调者知道参与者至少已经进入READY状态,说明参与者必然已经选择了“提交事务”。协调者因此可以把所有参与者移入PRECOMMIT状态,通过先发送一个″prepare-to-commit″消息,并通过在日志中写入一个提交记录和发送一个″global-commit″消息给所有工作中的参与者实施全局提交。

在COMMIT或ABORT状态时超时:协调者不知道参与者是否已经实施提交或夭折命令。然而,参与者至少已经处于PRECOMMIT(READY)状态(因为该协议在一个状态转换中是同步的),可以遵循下面参与者超时的第二种情况或第三种情况所述的终止协议。这样协调者不需要采取特别措施。

2)参与者超时(www.chuimin.cn)

参与者可能在INITIAL、READY和PRECOMMIT等三种状态下超时。

在INITIAL状态下超时:处理方式等同于2PC协议的。

在READY状态下超时:此时参与者已经选择了提交事务,但是还不知道协调者的全局决策。因为与协调者的通信已经丢失,所以可以通过重新选举一个协调者再执行终止协议。然后新的协调者按照终止协议终止该事务。

在PRECOMMIT状态下超时:此时参与者已经接收到″prepare-to-commit″消息,正在等待来自协调者的最后的″global-commit″消息。处理如上面的协调者超时的第二种情况。3PC协议如图10.18所示。

图10.18 3PC协议

下面分析最后两种可能选择终止协议的情况。一种是集中式,新协调者可以选择下面四种状态中的一种:WAIT、PRECOMMIT、COMMIT或ABORT。它把自己的状态发送给所有工作中的参与者,请求参与者接收这个状态。任何事先在新协调者出现前已经进入状态的参与者可以忘记新协调者的消息(它可能已经接收到老协调者的消息并且已经进入处理程序)。其他参与者完成其状态转换,并发送适当消息。一旦新协调者从参与者处获得消息,就按照如下方式终止。

●如果新协调者处于WAIT状态,则全局夭折事务。参与者可能处于INITIAL、READY、ABORT、PRECOMMIT状态。在前三种状态,没有问题。然而,如果参与者处于PRECOMMIT状态,等待的虽是″global-commit″消息,但却获得″global-abort″消息。而状态转换图不允许从PRECOMMIT到ABORT状态的变换。所以,我们必须改造它,让协议允许这种转换。

●如果新协调者处于PRECOMMIT状态,那么参与者可以处于READY、PRECOMMIT或COMMIT状态。任何参与者不可能处于ABORT状态。因此协调者将全局提交该事务,发送″global-commit″消息。

●如果新协调者处于ABORT状态,那么当第一个消息结束时,所有参与者都必须进入ABORT状态。

新的协调者在其处理过程中不维持参与者故障的轨迹。

2.恢复协议

3PC的恢复协议与2PC的恢复协议不同,其差别可以简述如下。

(1)协调者在WAIT状态时发生故障:参与者已经终止该事务,因此恢复时,协调者必须轮询大家以决定事务的命运。

(2)协调者在PRECOMMIT状态时发生故障:同样终止协议已经引导运行中的参与者终止。因为处理中允许从PRECOMMIT状态到ABORT状态的转换,协调者必须轮询大家以决定事务的命运。

(3)参与者在PRECOMMIT状态时发生故障:参与者必须轮询大家以确定其他参与者是如何终止事务的。

关于3PC协议的细节,有兴趣的读者可参阅参考文献[3]和参考文献[4]。