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曾被刪除過。