乐观复制算法-9.扩展乐观复制系统
9. 扩展乐观复制系统
本节讨论在乐观复制环境下如何支持大量副本节点。（支持大对象的问题在5.3节已经讨论过了）我们将讨论支持许多副本的挑战以及三条补救路线：一个结构化的通信拓扑，主动式的更新推送，以及高效网络。
9.1 评估冲突比例
支持多副本会产生两个问题：增加更新冲突以及传播延迟。更新冲突问题需要一些说明。Gray，Helland,O’Neil和Shasha指出多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系统，比如Usenet，Active Directory将这个概念进一步发展，将节点采用环型或树型结构连接，同时支持节点间的快捷路径，从而提高可用性和加速更新传播。
9.3 推送技术
讨论到目前为止，我们假设节点知道何时开始传播更新以及知道将更新传播给谁。在一些应用中这并不是个问题。比如，一些明确依赖手工同步的应用，以及一些仅管理少量对象可以采用周期拉取方式的应用（如，WEB镜像）。在更多的环境中，推送更新会更好—让节点承担推送更新到其它节点的责任—减少更新传播的延迟，消除拉取更新的开销。推送更新的挑战在于，它可能会发送重复更新，增加网络资源的消耗，以及增加更新处理的开销。我们从最简单的推送策略泛洪开始，然后讨论一些降低泛洪开销的技术。
9.3.1 Blind Flooding
泛洪是最简单的推送策略。当节点发生更新时，它将更新盲目地推送给它所连接的所有节点。接收节点使用Thomas`s写规则或者时间戳向量来过滤重复请求。该技术被应用在Usenet,NIS,Porcupine,以及很多关系型数据库中。
最简单的泛洪有一个明显的缺点：当一个节点域多个节点连接时，它会发送重复的更新。可以在发送更新前，猜测远程节点是否拥有本次更新，从而消除更新重复发送的问题。在多master系统中类似的信息无法避免，不管怎样，下面我们将看到用来解决该问题的多种技术。
9.3.2 连接状态监控技术
Rumor mongering和directional gossiping都是采用概率技术来避免重复更新。Rumor mongering从泛洪开始，但每个节点监控它所收到的重复请求。当重复请求的数目达到一个阈值时，节点将停止发送更新。在directional gossiping中，每个节点观察更新所经过不同路径的数目。一个不被多个路径所共享的内部链接会更重要，因为它可能是该节点链接到其它节点的唯一链接。因此，该节点会更加频繁地向这样的链接上发送更新。对于多个路径所共享的连接，节点将会减少更新的发送，因为其它节点可能会从不同路径上发送相同更新。
两种技术都是基于概率论的，因此他们可能会丢失发送给副本的更新。因此，为了实现可靠的更新传播，系统偶尔需要对泛洪方式进行重新排序，将更新发送到某些忽略了该更新的站点。模拟结果显示，在合理参数的设置下，这种方法能够消除重复更新，同时保持更新传播可靠度接近100%。
9.3.3 时间戳矩阵：估计远端节点的状态
另一种消除重复更新的技术，是让每一个节点估计远端节点处理的状态，仅发送远端节点可能缺少的更新。时间戳矩阵，在多master系统中被使用的例子包括Wuu and Bernstein 1984; Agrawal et al. 1997.
站点i保存一个时间戳矩阵TMi，一个N*M的时间戳矩阵（N是所有副本节点的数目，M是master节点的数目）。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提出的一些协议可以做到这点。
支持更多节点的系统将会面对更频繁地节点加入和离开。许多系统确实需要离线操作来添加或删除节点。（比如，NIS，Usenet）这样的设计仅仅在节点集合基本为静止状态可以采用。
添加和删除节点对于单master节点以及基于拉取的状态传输系统比较容易处理。事实上，这就是为什么WEB和FTP镜像乐于采用拉取，状态传输。它们系统在完全不同的管理域中可以轻松地添加新节点。
对于采用TV和ＴＭ的系统，前一节假设站点的数目是准确知道的，同时它们被连续编号。然而，节点的加入和离开是动态的；分配一个密集的编号并不可行。实际中并不可行，为了采用了一个稀疏标示符来从节点的唯一标示（如静态IP地址）映射到目录上。添加一个节点很简单：当收到的消息包含一个未知节点的标示符，则添加到向量或者矩阵中，并给它分配一个值为0的时间戳。
然而节点删除则是一个问题。当Z的时间戳向量中表示master节点Y的项无法访问时，Z必须区分节点Y是加入（Z可能还不知道节点Y的加入）还是离开（Z或许忘记了从时间戳向量中删除Y）。如果无法区分这两种情况，系统将不正确假定之前的时间戳为0，然后再一次地拉取已经获得的更新。
在Bayou中采用的方法如下。考虑节点X添加一个新的节点Y到系统中。Y节点的唯一标示是一个三元组，节点X的唯一标示，X时间戳向量的创建时间，（节点的唯一标示是一个任意分配long型数值）。节点创建事件将被写入日志并传送给其它节点。当其它节点Z收到消息包含Y的唯一标记时，同时节点Z的TV中没有Y，那么它可以区分添加和删除：
--如果Y名字中的时间戳向量小于TVz[X]，那么Z之前并没有收到Y的创建消息。Z将Y添加到TV中，并设定预值为0。
--否则，Z之间得到过Y的创建事件，TV中不存在Y的原因是Y曾被删除过。
