魅优论文范文网

 找回密码
 立即注册
查看: 9375|回复: 0
打印 上一主题 下一主题

[计算机理论] 一种改进3PC协议在分布式数据库安全中的研究

[复制链接]

8005

主题

8005

帖子

2万

积分

论坛元老

Rank: 8Rank: 8

积分
24099
跳转到指定楼层
楼主
发表于 2014-4-9 21:19:48 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
摘  要  在对传统恢复协议进行研究和比较后,提出了一种基于冗余技术的改进三段提交协议,该协议通过增加协调者副本来减少信息交换量和阻塞次数, 提高了事务的成功率和协议的性能,基本能实现事务执行的无阻塞,在正确的实现故障恢复的前提下,保证了分布式数据库的可靠性和安全性。
    关键词  分布式数据库 分布式恢复协议 故障恢复 三段提交协议


0  引言
    随着分布式数据库技术的广泛应用,其安全性也愈加受到人们的重视。目前,分布式数据库采用的安全性机制主要有:预防机制、监测机制、恢复机制。其中恢复机制是分布式数据库非常重要的组成部分。
1  3PC协议概述
1.1  三阶段提交协议(3PC)
    三阶段协议(3PC)也是是在二阶段协议的基础上发展而来的,主要的思想是将事务的提交过程进行延长,增加了发起者结点的预提交状态和参与者结点的准备提交状态(PREPARECOM2MIT) ,因而在发生故障时参与者可以有更多的选择余地。具体的说,如果是参与者发生了故障,那么它重新启动后就向其他未发生故障的参与者发送查询消息,如果已经有结点进入PREPARECOMMIT状态那么故障结点就可以提交,因为发起者发出PREPARE TO COMMIT命令的前提是收到了所有参与者结点的READY消息。如果任意一个参与者都没有收到PREPARE TO COMMIT命令,就要考虑事务的发起者是否出现了故障,按照协议,所有无故障的参与者可依据某种策略(如排队法) 来产生新的发起者来结束事务,新的发起者可以撤消事务以使各参与者尽快释放所占有的资源。如果原来的发起者发生故障时已经有参与者收到了准备提交命令,则新推选出的参与者可发出COMMIT 命令提交事务。
3PC虽然局部地解决了协议中的阻塞问题,但也会带来巨大的资源浪费,因为事务提交的效率总是受制于整个系统中最慢的结点或网络段。
1.2  3PC协议的工作原理
    在大多数情况下,二阶段提交协议是行之有效的,但是仍然会出现阻塞得情况,当参与者等待协调者的回答时,可能因为网络故障或协调者故障使之收不到回答信息而出现等待超时,这时事务进入等待状态。当故障一直持续时,则事务就一直处于阻塞状态,因此降低了整个系统的可用性。为此,引入3PC协议,这是一种非阻塞提交协议。这里所说的非阻塞的提交协议只是相对一定的故障模型,到目前为止还没有一种协议可以完全避免阻塞,但是可以通过一定的处理减少阻塞。
    三阶段提交协议(3PC)用三个阶段完成事务提交过程,分别为:参与者投票表决阶段、预提交阶段、协调者决策等三个阶段。其中,用两个阶段完成Abort,用三个阶段完成Commit。它的基本原理为:在2PC的参与者投票和协调者决策之间增加了“预提交”阶段。协调者在接收到所有参与者的提交票后发送一个全局预提交命令,当参与者接收到全局预提交命令之后,它就得知其他的参与者都投了提交票,从而确定自己在稍后肯定会执行提交操作,除非它失败了。每个参与者都对全局预提交发出确认消息,协调者一旦接收到所有参与者的确认消息就再发出“全局性提交”。3PC协议在站点失败,甚至是所有的站点都失败的情况下也不会带来阻塞。3PC协议中协调者与参与者的交互图1.1所示:


2  基于冗余技术的3PC协议的改进
    冗余技术在分布式数据库中是经常采用的一种技术,而在故障恢复协议中,对于比较关键的结点,也可以引用冗余技术来为这些站点产生后备结点,故障出现时一旦断定该结点死亡,立即采用选取后备结点来接管工作,这样可以节省等待的时间,并减少结点间通讯的次数从而提高整个协议的执行效率。[3]
2.1  改进协议的思想来源
    与2PC 相比,3PC 增加了一个预提交的缓冲状态。故障发生时,参与者可以有更多地选择的余地,如果是参与者本身发生了故障,就重启此结点事务,并向其它结点发送查询消息,来确认是否可以提交;如果发现所有结点都没有收到预提交命令,那么就考虑协调者发生了故障,此时需要参与者通过一定的算法选出新的协调者来接管事务处理工作。在3PC协议中,如果可以使得占多数结点的参与者不关心协调者是否存活,也就是说协调者的死亡与新协调者的产生对于参与者是透明的,那么整个系统的体系结构将更为清晰,效率也更高。
    在分布式数据库中经常采用适当增加数据的冗余度来提高系统的可靠性、可用性和改善系统的性能,通过在多个站点上存储数据的副本,使得当某一站点上的数据破坏时,系统仍可以正常运行。另外,系统还可以选择数据用户最近的数据副本进行操作,减少通信代价。[4]协调者在3PC中地位非常特殊而且非常重要,通过为其增加冗余来实现新的3PC协议,当前协调者被确认发生故障后,从其副本里选出合适的候选协调者,担任当前协调者的角色,已完成协调工作。但是,在新协议中,引入了超时技术和协调者之间在间隔时间内发消息询问的技术。2.2 改进协议的思想描述
    改进算法以传统3PC协议为基础,同时增加了冗余的协调者,但是对于参与者来说,冗余的协调者并不可见。正常情况下:当改进算法开始时,存在一个主协调者,该协调者负责协调参与者,其功能和传统的3PC协议中的协调者相同;同时,系统中存在一个从协调者队列,该协调者队列作为主协调者的后备,监听发送给主协调者的信息(因此从协调者也可以称作监听协调者),并执行与主协调者同样的动作,但是,该协调者并不向参与者发送各种命令,亦即,从协调者除了不发命令到参与者,其他动作同主协调者相同。因此,在任意时刻,从协调者和主协调者的状态完全一致。对于参与者来说,它们并不能感知主、从协调者,永远相信协调者不会死亡。从协调者通过在特定短时间间隔内和主协调者通信来感知主协调者是否存活,这个时间间隔应该远远小于传统3PC协议中的超时。从协调者从主协调者处得到回执消息,从而知道主协调者的存活。如果从协调者间隔一定时间(比如3秒钟)没有收到主协调者的消息,则认为主协调者失败。[5]
    当从协调者发现主协调者失败时,提升自己为主协调者,并接管已经失败的主协调者的工作,向参与者发送命令。该接管过程是无缝的。
    对于参与者来说,它并不需要关心当前的协调者是原来的主协调者,还是主协调者失败后由从协调者提升而来的。也就是说,主协调者的更替对其来说是透明的,它可以把所有的协调者看成一个整体,参与者只需永远信任协调者不会失败。

图2.1 改进3PC协议系统结构图
    图2.1为引入从协调者后的系统结构图,其中,虚线表示监听协调者对于参与者来说是透明的,在图中,监听协调者1作为协调者的冗余,监听协调者对列为协调者的冗余队列,队列中冗余副本按照站点标记作为优先级存入队列,当协调者死亡后,由监听协调者1替代协调者角色,当监听协调者1也死亡时,监听协调者队列再输出新的协调者,负责主协调者的工作。
    改进3PC协议中事务执行过程对于参与者根本不知道监听协调者的存在,对于监听协调者来说,对日志的处理和协调者保持一致,唯一的差别就是不向参与者发送消息,从而减少了通讯量,监听协调者与主协调者要以一定的频率交互信息,从而保证可以及检测到主协调者的状态,一旦死亡,监听协调者就马上取代主协调者进行协调工作,从而提高了系统的效率。[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
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

手机访问本页请
扫描左边二维码
         本网站声明
本网站所有内容为网友上传,若存在版权问题或是相关责任请联系站长!
站长联系QQ:7123767   myubbs.com
         站长微信:7123767
请扫描右边二维码
www.myubbs.com

QQ|Archiver|手机版|小黑屋|魅优论文范文网 ( 琼ICP备10200388号-7 )

GMT+8, 2024-5-13 07:48 , Processed in 0.059693 second(s), 20 queries .

Powered by 高考信息网 X3.3

© 2001-2013 大学排名

快速回复 返回顶部 返回列表