多复制服务器系统数据传输与负载分配研究.docVIP

多复制服务器系统数据传输与负载分配研究 　　[摘 要] 在多服务器系统中,数据分配和负载平衡是互相影响和互相联系的,但在很多情况下因为没有考虑到数据和负载的相互作用,网络的性能不是特别理想。因此,允许独立提交是解决阻塞问题的关键,在实际的Client/Server系统开发中,并不是所有的复制服务器上的数据都要自始至终维护一个一致的复制数据视图和进行即刻的更新传播,本文对之进行了行之有效的方法探讨。 　　[关键词] 服务器 网络传输 负载均衡 　　 　　采用多复制服务器系统是提高系统可用性最有希望的手段,但是,复制数据更新过程的阻塞问题是整个系统性能的一个瓶颈。复制数据更新的首要困难是控制多副本的一致性,通常采用的方法包括投票(Voting)和令牌(Token)传递方法,但是,这些方法的复杂性给实现带来困难,更新传播的另一个问题是保证事务的原子性,两阶段提交协议(2PC)是使用最多的保证事务原子性的提交协议,但是它由事务协调程序(Coordinator)决定各个参与者是否可以提交,这样就降低了系统的可用性,并增加了事务提交的延迟时间。网络环境的不健壮性使得所有参与结点同时提交的可能性减少,不可避免地造成能够正常提交的结点等待因失效不能提交的结点,而形成事务提交的阻塞。 　　一、多复制服务器的数据更新 　　我们假定在网络上有多个等同的复制服务器结点(简称结点),它们或者处于连接状态,或者处于非连接状态。但是在连接状态下通信是可靠的,网络各个结点之间能够保持消息的顺序,保证消息的内容正确到达,并且提供超时检测。系统出现故障的情况有两种,或者是各个结点之间处于非连接状态而不能通信,或者某个结点可能会因失效而不能正常工作,在每个结点有一个本地的逻辑时钟,在整个系统内对各个结点操作的定序可以利用Lamport邮戳机制解决。操作对象可以唯一标识,并且数据操作是一元的,它只影响到本地数据,每个事务中的数据操作不会跨越多个数据对象,在每个结点都有一个操作日志,其格式是(事务标识,邮戳,事务协调服务器编号,数据对象标识,操作标识,操作参数),其中邮戳是指记录在日志里某事务中操作的时间。在每一个结点建立一个用于数据协调目的的协调日志,其格式是(数据对象标识,结点标识),以便在数据协调时参考。 　　1、更新算法 　　算法1.更新发起点X对数据对象D开始更新 　　UpdateCoordinator(D) 　　{//更新发起点X对数据对象D开始更新 　　if(数据对象D的最后一次事务是失败的) 　　退出函数,或者先触发数据协调过程再调用此函数; 　　写Begin-Trans到操作日志; 　　发送Begin-Trans到各个复制结点,并且把此事务的超时时间发送给各结点; 　　while(事务写操作进行中) 　　{ 　　执行写操作Wi(D)并记录操作完成时间Ti; 　　记录写操作Wi(D)到操作日志; 　　等待各个结点的确认; 　　if(等待超时) 　　对于所有未收到确认消息的结点Y,插入(D,Y)到协调日志; 　　} 　　算法2.各个复制结点Y对数据对象D的更新 　　UpdateParticipator(D) 　　{//各个复制结点Y对数据对象D的更新 　　if(数据对象D的最后一次事务是失败的) 　　退出函数,或者先触发数据协调过程再调用此函数; 　　写Begin-Trans到操作日志; 　　while(还有本事务写操作) 　　{ 　　以原子方式提交更新事务并写Commit Trans到操作日志; 　　向发起结点X发送确认消息; 　　} 　　else 　　{ 　　对此事务执行本地回滚,清除此事务的操作日志; 　　标志此结点其数据对象D的最后一次事务是失败的; 　　} 　　} 　　2、更新算法分析 　　算法1和算法2保证了网络和结点失效时数据更新的原子性。由于网络连接失效对于更新发起点来说等价于一个或者多个结点失效,因此,我们只分析结点失效的情况。对于更新发起结点,在失效情况下事务无论如何都会顺利完成。下面着重只分析参与者结点失效的情况。(1)如果参与者在提交前失效,则在失效恢复时,该事务的操作被撤销,同时更新发起点在等待确认消息时超时,然后假定该参与者失效并在协调日志中记录;(2)如果参与者提交后失效,则在失效恢复时,虽然更新发起点假定该参与者失效并在协调日志中记录,但在本地的操作日志中已经提交了事务,所以该事务的操作不会被重新执行。总之在各种失效下,参与者都不会被阻塞,也不必执行远程恢复,而是由更新发起点记录未正常确认的结点信息通过以后的协调操作来达到数据一致。 　　二、多复制服务器的负载协调 　　我们先分析结点数据不一致的几种失效类型。由算法1与2易知,如果一个结