乐观复制算法-9.扩展乐观复制系统

9. 扩展乐观复制系统

       本节讨论在乐观复制环境下如何支持大量副本节点。(支持大对象的问题在5.3节已经讨论过了)我们将讨论支持许多副本的挑战以及三条补救路线:一个结构化的通信拓扑,主动式的更新推送,以及高效网络。

9.1 评估冲突比例

       支持多副本会产生两个问题:增加更新冲突以及传播延迟。更新冲突问题需要一些说明。GrayHelland,O’NeilShasha指出多master的乐观复制系统无法支持大量的master副本,因为它们会产生O(M2)的更新冲突,然而,单master系统将仅产生O(M)的更新冲突。直观上,在多master系统中并发更新将被调节,然而在单master系统利用类似两段锁技术,它们会被延迟或者丢弃。丢弃需要对更新间因果依赖关系的一次循环,同时丢弃发生的概率远小于冲突发生的比例(Prob(abortion)约等于Prob(conflict)2)Gray基于两个重要的假设来推导出它的结论:在所有节点上数据会以相同的概率更新,同时节点交换更新会以统一的随机性选择其他节点。这样的假设并不普遍适用。比如,在文件系统中的共享写操作就很少发生;文件被共享的越广泛,则越少被写。因此,实际中冲突问题有多严重仍不清楚。

       思考:上面这段最后的意思是否是说,最终人们还是不清楚实际系统中冲突情况有多严重,因为很难测量和建立模型分析真实的冲突情况。

       两个问题-更新冲突和传播延时-能通过以下方法缓和。1)结构化通信拓扑,这样发送到所有节点的更新将只需要很少的跳数。2)主动推送更新,在它们发生后越快越好。3)使用高效地网络协议来快速传播更新。我们将在下面部分讨论这三种方法。

9.2 通过控制通信拓扑结构来扩展系统

       我们所能发觉的冲突可能,可以通过节点间特定的连接方式来减少冲突。Figure7展示了一些例子。当站点采用星型结构连接,冲突的可能性被极大地减少。因为中心节点可以在解决完冲突更新后再将更新发送给边缘节点。

(原文注解:注意星型结构与单master系统的不同。单master串行化所有的写请求;星型结构的多master系统在中心处解决所有的冲突。(我不认为是所有的冲突都可以在中心节点解决))(思考:Robin中心节点向客户端节点发送更新时,仍需要在客户端进行更新冲突解决。CVS也存在这个问题。所以我觉得中心节点解决完冲突后,在边缘节点仍会需要对冲突的解决。)星型拓扑能更快的传播更新,因为任意更新传播到任意节点都只需要两跳。CVS是一个大家所熟知的例子。两层复制时星型结构的衍化。这里,站点被划分为强连接的“核心节点”以及弱连接的“移动节点”。核心节点通常采用悲观复制算法在节点间保持一致性,叶子节点采用乐观复制并仅与核心节点连接。注意,星型拓扑和两层拓扑仍需要解决多master乐观复制系统的所有问题--可靠的更新传播,调度,冲突解决--但它们能有更好的扩展性,不过这是以牺牲通信的灵活性为代价。与之相反,每个节点能随机地与任意节点通信的拓扑结构,会有最快的传播速度以及最高的冲突比例。

       这些方法并不是灵丹妙药。首先,它们仍会在传播速度,负载均衡,以及可用性上付出代价。星型拓扑给中心节点过度的压力,在实际环境中会减慢更新传播。同时,中心节点会成为单点故障。随机拓扑,好的方面在于具有高可用性,负载可以被最终分解到所有节点。其次,站点无法总是可以选择节点进行通信,特别是在移动自组网络环境中,通信拓扑取决于人们的需求以及连接设备。

       其他几种拓扑结构也被用于真实世界的系统中。很多采用树形拓扑,它混合了星型和随机拓扑的属性。Roam将中心节点连接成一个环,放开了其它节点的连接。多master系统,比如UsenetActive Directory将这个概念进一步发展,将节点采用环型或树型结构连接,同时支持节点间的快捷路径,从而提高可用性和加速更新传播。

9.3 推送技术

       讨论到目前为止,我们假设节点知道何时开始传播更新以及知道将更新传播给谁。在一些应用中这并不是个问题。比如,一些明确依赖手工同步的应用,以及一些仅管理少量对象可以采用周期拉取方式的应用(如,WEB镜像)。在更多的环境中,推送更新会更好让节点承担推送更新到其它节点的责任减少更新传播的延迟,消除拉取更新的开销。推送更新的挑战在于,它可能会发送重复更新,增加网络资源的消耗,以及增加更新处理的开销。我们从最简单的推送策略泛洪开始,然后讨论一些降低泛洪开销的技术。

9.3.1 Blind Flooding

       泛洪是最简单的推送策略。当节点发生更新时,它将更新盲目地推送给它所连接的所有节点。接收节点使用Thomas`s写规则或者时间戳向量来过滤重复请求。该技术被应用在Usenet,NIS,Porcupine,以及很多关系型数据库中。

       最简单的泛洪有一个明显的缺点:当一个节点域多个节点连接时,它会发送重复的更新。可以在发送更新前,猜测远程节点是否拥有本次更新,从而消除更新重复发送的问题。在多master系统中类似的信息无法避免,不管怎样,下面我们将看到用来解决该问题的多种技术。

9.3.2 连接状态监控技术

       Rumor mongeringdirectional gossiping都是采用概率技术来避免重复更新。Rumor mongering从泛洪开始,但每个节点监控它所收到的重复请求。当重复请求的数目达到一个阈值时,节点将停止发送更新。在directional gossiping中,每个节点观察更新所经过不同路径的数目。一个不被多个路径所共享的内部链接会更重要,因为它可能是该节点链接到其它节点的唯一链接。因此,该节点会更加频繁地向这样的链接上发送更新。对于多个路径所共享的连接,节点将会减少更新的发送,因为其它节点可能会从不同路径上发送相同更新。

       两种技术都是基于概率论的,因此他们可能会丢失发送给副本的更新。因此,为了实现可靠的更新传播,系统偶尔需要对泛洪方式进行重新排序,将更新发送到某些忽略了该更新的站点。模拟结果显示,在合理参数的设置下,这种方法能够消除重复更新,同时保持更新传播可靠度接近100%

9.3.3 时间戳矩阵:估计远端节点的状态

       另一种消除重复更新的技术,是让每一个节点估计远端节点处理的状态,仅发送远端节点可能缺少的更新。时间戳矩阵,在多master系统中被使用的例子包括Wuu and Bernstein 1984; Agrawal et al. 1997.

       站点i保存一个时间戳矩阵TMi,一个N*M的时间戳矩阵(N是所有副本节点的数目,Mmaster节点的数目)。TMi[i]是节点i的时间戳向量。其它TMi的行,是节点i估计其它节点保存的时间戳向量。因此,TMi[k][j]=c,表示节点i认为节点k收到来自节点j更新的时间戳最少也是c。更新传播的流程如Figure8所示,与Figure6的时间戳向量处理类似。唯一的不同是,当发送更新给节点j,节点i采用TMi[j]作为对节点j时间戳向量的估计,而不是从节点j接收一个向量。

9.4 添加和移除master节点

       时间戳向量每一项表示一个master节点。因此,它的空间复杂度随着系统规模而线性增长。通过标示符来区分master节点比数字1…M要方便许多,比如节点的IP地址;时间戳向量的记录是稀疏的,所有节点的标示符对应这些节点上时间戳向量的一行。添加一个新的master是相对容易的。

       删除一个永久离开系统的master节点则比较复杂。Z的时间戳向量中表示master节点Y的项无法访问时,Z必须区分节点Y是加入(Z可能还不知道节点Y的加入)还是离开(Z或许忘记了从时间戳向量中删除Y)。如果无法区分这两种情况,会造成系统重复的拉取已经应用的更新。因此,所有节点必须一致地移除掉TV中的项,当master节点离开时。Ratner1998;Peterson et al.1997;Adya and Liskov 1997提出的一些协议可以做到这点。

       支持更多节点的系统将会面对更频繁地节点加入和离开。许多系统确实需要离线操作来添加或删除节点。(比如,NISUsenet)这样的设计仅仅在节点集合基本为静止状态可以采用。

       添加和删除节点对于单master节点以及基于拉取的状态传输系统比较容易处理。事实上,这就是为什么WEBFTP镜像乐于采用拉取,状态传输。它们系统在完全不同的管理域中可以轻松地添加新节点。

       对于采用TV和TM的系统,前一节假设站点的数目是准确知道的,同时它们被连续编号。然而,节点的加入和离开是动态的;分配一个密集的编号并不可行。实际中并不可行,为了采用了一个稀疏标示符来从节点的唯一标示(如静态IP地址)映射到目录上。添加一个节点很简单:当收到的消息包含一个未知节点的标示符,则添加到向量或者矩阵中,并给它分配一个值为0的时间戳。

       然而节点删除则是一个问题。当Z的时间戳向量中表示master节点Y的项无法访问时,Z必须区分节点Y是加入(Z可能还不知道节点Y的加入)还是离开(Z或许忘记了从时间戳向量中删除Y)。如果无法区分这两种情况,系统将不正确假定之前的时间戳为0,然后再一次地拉取已经获得的更新。

       Bayou中采用的方法如下。考虑节点X添加一个新的节点Y到系统中。Y节点的唯一标示是一个三元组,节点X的唯一标示,X时间戳向量的创建时间,(节点的唯一标示是一个任意分配long型数值)。节点创建事件将被写入日志并传送给其它节点。当其它节点Z收到消息包含Y的唯一标记时,同时节点ZTV中没有Y,那么它可以区分添加和删除:

       --如果Y名字中的时间戳向量小于TVz[X],那么Z之前并没有收到Y的创建消息。ZY添加到TV中,并设定预值为0

       --否则,Z之间得到过Y的创建事件,TV中不存在Y的原因是Y曾被删除过。



来自为知笔记(Wiz)


posted on 2013-05-23 21:25  修炼思维  阅读(238)  评论(0编辑  收藏  举报