乐观复制算法-附件B-Version vectors算法介绍和不足
附件B-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的开销就很大。
