Version vectors算法介紹和不足

        Version vectors算法介紹和不足

         Version vectors算法在分佈式操作系統LOCUS中提出【Pope et al.1981】，用於檢查分佈式系統中，在網絡中斷期間對數據進行的併發修改是否存在衝突。下面對Version vectors算法進行說明，然後再論述該算法的不足。

         Version vectors算法介紹

         每一個副本節點對於文件f保存一個版本向量 version vectors，（包含多個版本元素的向量）。Version vectors用來記錄不同節點對於該文件的修改。向量含有N個元素，N爲擁有該文件的節點數。向量中每一個元素，比如( Si : vi )表示，節點Si上對文件f進行了共vi次修改。通過比較不同節點保存的version vectors向量可以發現節點間的更新衝突。

         先介紹一個概念，向量間的包含關係。對於同一個文件f的兩個不同向量V和V’，即兩個不同節點各自保存的向量。如果向量V中的每一個元素vi >= vi’，那麼就稱向量V包含向量V’，V’包含於V。

         根據這個關係，可以定義節點更新間的衝突。對於同一個文件f的兩個向量V和V’,如果向量V不包含V’，同時V’也不包含V,則視爲節點更新衝突。比如對於文件f，節點A上的向量V=<A:3,B:1,C:2>，節點B上的向量V’=<A:2,B:4,C:2>。

         因爲 3>2, 1<4, 2=2所以V不包含V’；同時，2<3, 4>1, 2=2，V’也不包含V，故在節點A和節點B上進行的修改是衝突的。

         假設文件f，在狀態<A:2,B:1,C:2>時，節點A和B是一致的。因網絡中斷，用戶在A上進行了一次修改，在B上對文件進行了2次修改，這樣就形成前面提到的兩個向量。利用Version Vectors算法可以準確的識別出在A，B上進行的修改是衝突的。

         Version vectors算法不足

a.       僅對單個文件的併發修改有效，對於多個對象的修改無法識別。

對於單一文件系統，當一個文件被編輯時，如果對其目錄進行重命名、刪除等操作，是不允許的。必須在文件保存後，才能對目錄進行重命名或刪除操作。但對於分佈式系統，用戶可以在兩個節點上分別進行目錄重命名和文件編輯操作。利用Version vectors算法是無法識別這樣的併發修改。

因爲Version Vectors是針對每個文件進行信息的保存。上面的情況，目錄重命名會影響到多個文件，但修改的僅是該目錄的Version Vector向量。當兩個節點交換更新時就無法識別衝突。當然我們可以修改對Version Vector向量的更新過程，比如當對目錄進行操作時，遞歸的更新其所含文件、子目錄的Version Vectors。這意味着需要將不同應用的語義信息移入答Version Vectors算法的更新過程中。

Version Vectors對於單個文件，簡單併發更新可以識別。對於多個對象，且對象間存在一定語義約束的情況，Version Vectors算法無法適用。

b.      持有文件副本的節點不能靈活擴展

Version vectors從一開始就規定了該文件持有的副本數。當需要有更多的節點持有該副本時，需要輔助的算法進行。在Dynamo系統中也採用了Version Vectors算法。假設Dynamo中對於每個文件默認提供三個副本，那麼就會有三臺電腦同時持有該文件。如果對文件的請求增多，需要增加該文件的副本來滿足更多的請求。這時就需要擴展已持有該文件副本節點的Version vector向量，讓向量支持更多的元素，從而支持新的節點加入。在節點頻繁伸縮情況下，Version vector的開銷就很大。