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的開銷就很大。