我正在开发一个基本上需要存储Map<String,Set<String>>的应用程序（好吧，它比那复杂得多，但这是基本的想法）而且我打算做很多事情
Set<String> strings = storeClient.get("some key");
strings.add("some string");
storeClient.put("some key", strings);
所以我想要了解的是，StoreClient#put什么时候会InconsistencyResolver创建一个由StoreClient#put解决的不一致性，以及什么时候{{3}}只会破坏该值？
答案 0 :(得分：2)
免责声明：我很长一段时间没有使用过Voldemort，现在在Riak的Basho工作。也就是说，我思考这是一个很容易回答引用的问题，但缺乏真实的文档（以及构建谷歌搜索的难度不返回东西关于哈利波特）实际上提出了一个真正的挑战 - 你提出了一个非常好的问题。我相信下面的内容是正确的。
因为你在谈论put()的版本，你没有发送版本（矢量时钟）并且不关心数据库中当前是什么或者什么...基本上它只是去覆盖任何（如果有的话）。
对于他们的体系结构，他们有任何给定（散列）密钥的主（协调）节点的概念，在复制到环上的其他节点之前，它们总是首先写入，这允许它们覆盖/清除任何先前版本的值。我猜他们正在做这个比较作为CAS或其他受保护（通过锁）操作，以防止任何并发问题。使用BerkeleyDB后端时，他们很可能只是使用其内置的事务/锁定机制。鉴于此，您应该很少遇到客户需要解决它们的冲突值/版本。
然而，根据this post from Jay Kreps他说：
......并发 当不同的客户端（或请求路由器）不同意时，会出现版本 是否有特定服务器可用。在常见的情况下 这不会发生 - 每个密钥都有一个主服务器，我们总是写 到那个服务器首先允许我们立即垃圾收集 任何旧版本。但是在一位作家认为的情况下 主人失败了，另一个人认为它已经失败了，这些都是可能的 两台服务器接受冲突的写入。这是必要的 存储引擎能够保留这两个版本，直到 客户可以解决它们。
这就是InconsistencyResolver进来的地方。
当使用put()的版本时，你也发送了之前获取的版本，（主）服务器将返回一个指示，表明版本已失效，客户端将抛出{{1} }。但是，在失败/恢复节点的情况下......可能可能并发版本可能在集群中，只有客户端可以通过ObsoleteVersionException解析它们。