接上一篇日志（http://www.cnblogs.com/star-star/archive/2013/05/15/3080162.html）最后
说到解决版本冲突的两种方法，接下来继续进行深入。
当版本冲突时，我们可能需要根据额外的信息来作为依据，来进行版本选择。
这时候，我们可以将原先版本(Node, Tag)扩展为(Node, Tag, Timestamp)加上一个时间戳字段，作为一个额外的依据进行判断。
这样，当我们同步A, B, C节点的数据时候，
假设A节点第一次初始化数据时间戳为1， B节点修改数据时间戳为2， C节点修改时间戳为3，B节点则能根据修改时间，进行版本选择，最后A，B， C同步为:
A节点 data: 300 version: [(A, 1, 1), (B, 1, 2), (C, 1, 3)] B节点 data: 300 version: [(A, 1, 1), (B, 1, 2), (C, 1, 3)] C节点 data: 300 version: [(A, 1, 1), (B, 1, 2), (C, 1, 3)]
而上面是在服务器间数据进行同步时候自动做出的版本修复选择。
有时候我们可以把这种选择权利交给客户端，让客户端进行读取操作时候，按照客户端自定义的规则来进行版本修复merge。(我感觉这有点像版本控制软件给程序员报告冲突之后，让程序员手动进行merge)
在客户端进行选择的时候，一定要选择几个节点的数据作为依据进行比对才能进行版本选择，那到底该怎么选择节点呢？？抽屉原理= =
假设W代表写入的节点数, R代表读出的节点数，节点数为N，则必须满足R + W > N
按上篇博客的例子，
假设有三个服务器节点：
N = 3
write时:
只需要写入一个节点，即算write操作成功, W = 1
read时:
R + W > N
R + 1 > 3
R >= 3
所以当我们按照写入一节点成功的场景，则需要读出三个节点的数据进行版本比对。
取出节点数据后，可能按照时间戳进行判断，merge出最新的版本，然后往节点写入写的数据和版本信息。。。
posted on
