Vector Clock 简介

引言：

最近重读http://book.mixu.net/distsys/ebook.html，在分布式文件系统，如何掌握写入内容的先后关系是重要的一环，因为在并发写入的过程中，可能会导致多个版本同时出现的情况，但是使用物理时钟显然是不靠谱的，所以我们采用一种逻辑时钟来为对象构建一种偏序的（partial ordering）的时序集合，同时这个也是Amazon在他们的Dynamo中的实践原理。

简介：

VectorClock是一种用向量来表示偏序关系的逻辑时钟，从数据结构上可以理解为一个集合内包含所有节点的“时间戳”，当然这个时间戳并不是物理意义上的时间（也有些实践会同时加入timestamps以解决冲突问题），而是由程序赋予的逻辑计数（count），{Node1:0,Node2:2,Node3:3.......}，如果我们已经统一了向量内的位置对应的node，那么时钟可以直接用一个{0,2,3}来表示。

对于每一个分布式存储的对象副本都有这样一个时间戳，那么存在一下几种关系：

a： 本机：{0，0，1} 消息：{0，1，2}。消息的每个节点的count都大于等于本机的，那么舍弃本机，同步消息
b: 本机：{0，1，2} 消息：{0，1，1}。消息的每个节点的count都小于等于本机的，那么舍弃消息，保留本机
c: 本机：{0，3，1} 消息：{0，1，2}。出现冲突，有的大，有的小，无法判断出来到底谁是最新版本。就要进行冲突仲裁。

举例：

假设有一个K-V数据库，{K，V}为一个分布式对象，通过3个副本保存，分别在Node 1,Node 2, Node 3上，初始的vectorclock为 {0,0,0}

• 首先写入，Node1，那么node1 的vclock会增加node1的count，可以理解为node1修改了{K,V}，先在的vclock就变为{1,0,0}
• 此时Node1将这个副本及其vclock分发给Node2和Node3，因为此时这两个Node都是{0，0，0}的状态，所以符合a关系，2，3同步
• 此时又有一次在Node1的写入，变为{2,0,0}，此时Node1接到了来到了Node2的消息，此时符合b关系，Node1保留
• 此时有了一次Node2的写入，Node2的vclock变为{1,1,0}，但此时Node1的上次写入没有传递给Node2，Node2觉得自己这里就是对了，如果这个时候Node1的消息来了就会产生3关系，冲突。

其实在我们平时使用Dropbox同步盘的时候就会出现这种情况，当你在进行频繁保存的时候，上一次的保存结果告诉了服务端，然后你在服务端返回已同步修改前又保存了一次，结果服务端不愿意了，怎么你本地的和我的对不上了，直接留下了两个版本和时间戳让用户自己去选择。

实现：

function VectorClock(value) {
// expressed as a hash keyed by node id: e.g. { node1: 1, node2: 3}
    this.value = value || {};
} 
VectorClock.prototype.get = function() {
    return this.value;
};
//根据写入节点增加vector clock
VectorClock.prototype.increment = function(nodeId) {
    if(typeof this.value[nodeId] == 'undefined') {
        this.value[nodeId] = 1;
    } else {
        this.value[nodeId]++;
    }
};
VectorClock.prototype.merge = function(other) {
    var result = {}, last,
        a = this.value,
        b = other.value;
    // This filters out duplicate keys in the hash
    (Object.keys(a)
        .concat(b))
        .sort()
        .filter(function(key) {
            var isDuplicate = (key == last);
            last = key;
            return !isDuplicate;
        }).forEach(function(key) {
            result[key] = Math.max(a[key] || 0, b[key] || 0);
        });
    this.value = result;
};

小结：

1. 关于冲突仲裁：一种解决方法是请求用户的介入，另一种可以通过引入辅助的时间戳来判断。

2. 一般3个副本就足够

3. Quorum NRW模型：

   N: 复制的节点数量

   R: 成功读操作的最小节点数

   W: 成功写操作的最小节点数只需W + R > N，就可以保证强一致性。

   ​

   当需要高可写的系统时，可以设置W=1 R=3
   当需要高可读的系统时，可以设置W=3 R=1 （写的效率较低）