^[6]

3  改进3PC协议对故障的处理

3.1 站点故障

    3.1.1对于参与者，不管它在事务开始前，或在事务的进行过程中出现故障，协调者在发现时都要用本地的监听协调者来模拟它的活动，并在参与者恢复后由监听协调者把在故障过程中成功提交的事务交给它重新执行。因此，参与者的故障在这种协议下是可以恢复的。     3.1.2 对于协调者，如果在它在日志中写入“全部提交”或“全部夭折”前或者在日志中写入“全部夭折”后，写入“事务结束”前发生故障，各参与者由于协调者出现故障而得不到协调者的命令，进而使各自的子事务夭折。这种情况下，在协调者故障消除后重启时，重启过程将通过检查日志找出这类未完成事务并把它们夭折。这样，整个事务就以最终夭折的形式得到恢复。^[7]     3.1.3 对于协调者，如果在它在日志中写入“全部提交”后，写入“事务结束”前发生故障，就可能会出现一些参与者收到了“提交”命令，而另外一些参与者却没有收到的情况。而这种情况很可能会导致在一个分布式事务中出现部分参与者提交，部分参与者夭折，进而破坏事务的原子性。为了能够从这种故障状态中恢复，协调者在故障消除后重启的过程中，必须得从日志中找出这类未完成的事务，让它们重新执行并得到提交。当然，对于那些已成功提交过的站点，重新执行的结果应该和以前一样。

3.2 报文丢失故障

    当系统有些控制报文丢失时，改进3PC协议采用超时法处理：     3.2.1协调者没有及时发出“开始报文”，导致参与者等待超时，这时参与者决定夭折。     3.2.2 协调者等待参与者投票结果超时，这时协调者决定夭折。     3.2.3 当系统处于“赞成”提交状态，等持“准备提交”命令时出现超时，这时进入恢复处理过程。     3.2.4 当参与者处于“准备提交”状态等待协调者的“提交”命令出现超时，也进入恢复处理，这时只要有至少有一个参与者处于活动状态，子事务就不会阻塞。因为恢复后的参与者可以从活动的子事务得到有关提交处理的信息，从而得知协调者的决定，依据协调者的决定确定自己应做的处理。3PC协议可以保证一个参与者在其它任何一个活动的参与者处于“赞成”提交状态时，不可能进入“提交”状态；以及一个参与者在另一个参与者进入“提交”状态或任何一个参与者都进入了“准备提交”状态时不能进入“夭折”状态。     当某个协调者站点检测出它的一个参与站点出现故降，在3PC协议中的处理过程与2PC协议中的处理方法一样．并且还要依据情况启动监听协调者线程模拟故障站点。     综上所述，寻找一种更为高效可靠的恢复协议将作为以后分布式事务处理的重点，在故障发生时要保证分布式数据库系统的安全性，还需要进一步研究和改进分布式数据恢复技术，力求在发生任何的系统软、硬件故障时，都能在提高分布式处理性能的前提下保证数据的正确、及时的恢复。实验证明，基于冗余技术的改进三段提交协议，通过增加协调者副本来减少信息交换量和阻塞次数, 提高了事务的成功率和协议的性能，在正确的实现故障恢复的前提下，保证了分布式数据库的可靠性和安全性。

参考文献

    [1]   张福涛.分布式数据库的安全研究与实现：[硕士学位论文]. 南京工业大学，2005     [2]   宋静,刘心松等. 一种改进的2PC 协议及其性能. 微计算机信息.2006.6     [3]   D.Daniels.Query compilations in a distributed database system. IBM Res. Rep. RJ 3423, IBM, 1982.72-103     [4]   Microsoft Corporation： Microsoft SQL Server 6.5, Guide to Microsoft Distributed Transaction C oordinator,1996.150-160     [5]   D Skeen. Non - blocking commit protocols. The ACM SIGMOD Conf on Management of Data, Ann Arbor, Michigan, 1981.50-53     [6]   George Coulouris, Jean Collinear and Tim Kind berg. Distributed System Concepts and Design,2rd ED. Addison-Wesley.1994.36-39