一种改进3pc协议在分布式数据库安全中的研究

1 / 8一种改进 3PC 协议在分布式数据库安全中的研究摘 要 在对传统恢复协议进行研究和比较后，提出了一种基于冗余技术的改进三段提交协议，该协议通过增加协调者副本来减少信息交换量和阻塞次数, 提高了事务的成功率和协议的性能,基本能实现事务执行的无阻塞，在正确的实现故障恢复的前提下，保证了分布式数据库的可靠性和安全性。 关键词 分布式数据库 分布式恢复协议 故障恢复 三段提交协议 0 引言 随着分布式数据库技术的广泛应用，其安全性也愈加受到人们的重视。目前，分布式数据库采用的安全性机制主要有：预防机制、监测机制、恢复机制。其中恢复机制是分布式数据库非常重要的组成部分。1 3PC 协议概述 三阶段提交协议 三阶段协议(3PC)也是是在二阶段协议的基础上发展而来的，主要的思想是将事务的提交过程进行延长，增加了发起者结点的预提交状态和参与者结点的准备提交状态(PREPARECOM2MIT) ，因而在发生故障时参与者可以有更多的选择余地。具体的说，如果是参与者发生了故障，那么它重新启动后就向其他未发生故障的参与者发送查询消息，如果已经有结点进入PREPARECOMMIT 状态那么故障结点就可以提交，因为发起者发出 PREPARE TO COMMIT 命令的前提是收到了所有参与者2 / 8结点的 READY 消息。如果任意一个参与者都没有收到PREPARE TO COMMIT 命令，就要考虑事务的发起者是否出现了故障，按照协议，所有无故障的参与者可依据某种策略(如排队法) 来产生新的发起者来结束事务，新的发起者可以撤消事务以使各参与者尽快释放所占有的资源。如果原来的发起者发生故障时已经有参与者收到了准备提交命令，则新推选出的参与者可发出 COMMIT 命令提交事务。3PC 虽然局部地解决了协议中的阻塞问题，但也会带来巨大的资源浪费，因为事务提交的效率总是受制于整个系统中最慢的结点或网络段。 3PC 协议的工作原理 在大多数情况下，二阶段提交协议是行之有效的，但是仍然会出现阻塞得情况，当参与者等待协调者的回答时，可能因为网络故障或协调者故障使之收不到回答信息而出现等待超时，这时事务进入等待状态。当故障一直持续时，则事务就一直处于阻塞状态，因此降低了整个系统的可用性。为此，引入 3PC协议，这是一种非阻塞提交协议。这里所说的非阻塞的提交协议只是相对一定的故障模型，到目前为止还没有一种协议可以完全避免阻塞，但是可以通过一定的处理减少阻塞。 三阶段提交协议(3PC)用三个阶段完成事务提交过程，分别为：参与者投票表决阶段、预提交阶段、协调者决策等三个阶段。其中，用两个阶段完成 Abort，用三个阶段完成 Commit。它的基本原理为：在 2PC 的参与者投票和协调3 / 8者决策之间增加了“预提交”阶段。协调者在接收到所有参与者的提交票后发送一个全局预提交命令，当参与者接收到全局预提交命令之后，它就得知其他的参与者都投了提交票，从而确定自己在稍后肯定会执行提交操作，除非它失败了。每个参与者都对全局预提交发出确认消息，协调者一旦接收到所有参与者的确认消息就再发出“全局性提交” 。3PC 协议在站点失败，甚至是所有的站点都失败的情况下也不会带来阻塞。3PC 协议中协调者与参与者的交互图所示：2 基于冗余技术的 3PC 协议的改进 冗余技术在分布式数据库中是经常采用的一种技术，而在故障恢复协议中，对于比较关键的结点，也可以引用冗余技术来为这些站点产生后备结点，故障出现时一旦断定该结点死亡，立即采用选取后备结点来接管工作，这样可以节省等待的时间，并减少结点间通讯的次数从而提高整个协议的执行效率。 3 改进协议的思想来源 与 2PC 相比，3PC 增加了一个预提交的缓冲状态。故障发生时，参与者可以有更多地选择的余地，如果是参与者本身发生了故障，就重启此结点事务，并向其它结点发送查询消息，来确认是否可以提交；如果发现所有结点都没有收到预提交命令，那么就考虑协调者发生了故障，此时需要参与者通过一定的算法选出新的协调者来接管事务处理工作。在 3PC 协议中，如果可以4 / 8使得占多数结点的参与者不关心协调者是否存活，也就是说协调者的死亡与新协调者的产生对于参与者是透明的，那么整个系统的体系结构将更为清晰，效率也更高。 在分布式数据库中经常采用适当增加数据的冗余度来提高系统的可靠性、可用性和改善系统的性能，通过在多个站点上存储数据的副本，使得当某一站点上的数据破坏时，系统仍可以正常运行。另外，系统还可以选择数据用户最近的数据副本进行操作，减少通信代价。4协调者在 3PC 中地位非常特殊而且非常重要，通过为其增加冗余来实现新的3PC 协议，当前协调者被确认发生故障后，从其副本里选出合适的候选协调者，担任当前协调者的角色，已完成协调工作。但是，在新协议中，引入了超时技术和协调者之间在间隔时间内发消息询问的技术。 改进协议的思想描述 改进算法以传统 3PC 协议为基础，同时增加了冗余的协调者，但是对于参与者来说，冗余的协调者并不可见。正常情况下：当改进算法开始时，存在一个主协调者，该协调者负责协调参与者，其功能和传统的 3PC 协议中的协调者相同；同时，系统中存在一个从协调者队列，该协调者队列作为主协调者的后备，监听发送给主协调者的信息，并执行与主协调者同样的动作，但是，该协调者并不向参与者发送各种命令，亦即，从协调者除了不发命令到参与者，其他动作同主协调者相同。因此，在任意时刻，从协调者5 / 8和主协调者的状态完全一致。对于参与者来说，它们并不能感知主、从协调者，永远相信协调者不会死亡。从协调者通过在特定短时间间隔内和主协调者通信来感知主协调者是否存活，这个时间间隔应该远远小于传统 3PC 协议中的超时。从协调者从主协调者处得到回执消息，从而知道主协调者的存活。如果从协调者间隔一定时间没有收到主协调者的消息，则认为主协调者失败。5 当从协调者发现主协调者失败时，提升自己为主协调者，并接管已经失败的主协调者的工作，向参与者发送命令。该接管过程是无缝的。 对于参与者来说，它并不需要关心当前的协调者是原来的主协调者，还是主协调者失败后由从协调者提升而来的。也就是说，主协调者的更替对其来说是透明的，它可以把所有的协调者看成一个整体，参与者只需永远信任协调者不会失败。图 改进 3PC 协议系统结构图 图为引入从协调者后的系统结构图，其中，虚线表示监听协调者对于参与者来说是透明的，在图中，监听协调者 1 作为协调者的冗余，监听协调者对列为协调者的冗余队列，队列中冗余副本按照站点标记作为优先级存入队列，当协调者死亡后，由监听协调者 1 替代协调者角色，当监听协调者1 也死亡时，监听协调者队列再输出新的协调者，负责主协调者的工作。 改进 3PC 协议中事务执行过程对于参与者根本不知道监听协调者的存在，对于监听协调者来说，对日6 / 8志的处理和协调者保持一致，唯一的差别就是不向参与者发送消息，从而减少了通讯量，监听协调者与主协调者要以一定的频率交互信息，从而保证可以及检测到主协调者的状态，一旦死亡，监听协调者就马上取代主协调者进行协调工作，从而提高了系统的效率。 63 改进 3PC 协议对故障的处理 站点故障 对于参与者，不管它在事务开始前，或在事务的进行过程中出现故障，协调者在发现时都要用本地的监听协调者来模拟它的活动，并在参与者恢复后由监听协调者把在故障过程中成功提交的事务交给它重新执行。因此，参与者的故障在这种协议下是可以恢复的。 对于协调者，如果在它在日志中写入“全部提交”或“全部夭折”前或者在日志中写入“全部夭折”后，写入“事务结束”前发生故障，各参与者由于协调者出现故障而得不到协调者的命令，进而使各自的子事务夭折。这种情况下，在协调者故障消除后重启时，重启过程将通过检查日志找出这类未完成事务并把它们夭折。这样，整个事务就以最终夭折的形式得到恢复。7 对于协调者，如果在它在日志中写入“全部提交”后，写入“事务结束”前发生故障，就可能会出现一些参与者收到了“提交”命令，而另外一些参与者却没有收到的情况。而这种情况很可能会导致在一个分布式事务中出现部分参与者提交，部分参与者夭折，进而破坏事务的原子性。为7 / 8了能够从这种故障状态中恢复，协调者在故障消除后重启的过程中，必须得从日志中找出这类未完成的事务，让它们重新执行并得到提交。当然，对于那些已成功提交过的站点，重新执行的结果应该和以前一样。 报文丢失故障 当系统有些控制报文丢失时，改进 3PC 协议采用超时法处理： 协调者没有及时发出“开始报文” ，导致参与者等待超时，这时参与者决定夭折。 协调者等待参与者投票结果超时，这时协调者决定夭折。 当系统处于“赞成”提交状态，等持“准备提交”命令时出现超时，这时进入恢复处理过程。 当参与者处于“准备提交”状态等待协调者的“提交”命令出现超时，也进入恢复处理，这时只要有至少有一个参与者处于活动状态，子事务就不会阻塞。因为恢复后的参与者可以从活动的子事务得到有关提交处理的信息，从而得知协调者的决定，依据协调者的决定确定自己应做的处理。3PC 协议可以保证一个参与者在其它任何一个活动的参与者处于“赞成”提交状态时，不可能进入“提交”状态；以及一个参与者在另一个参与者进入“提交”状态或任何一个参与者都进入了“准备提交”状态时不能进入“夭折”状态。 当某个协调者站点检测出它的一个参与站点出现故降，在 3PC 协议中的处理过程与 2PC协议中的处理方法一样并且还要依据情况启动监听协调者线程模拟故障站点。 综上所述，寻找一种更为高效可靠8 /