我正在开发一个基本上需要存储 a 的应用程序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破坏价值？
免责声明：我很长时间没有使用 Voldemort，现在在 Riak 上的 Basho 工作。也就是说，我认为这将是一个很容易通过引用来回答的问题，但是缺乏真正的文档（以及构建不返回有关哈利波特的内容的谷歌搜索的困难）实际上提出了一个真正的挑战 - 你提出了一个非常好问题。我相信以下是正确的。
由于您谈论的是put()的版本，您没有发送版本（矢量时钟）并且不关心数据库中是否或当前是什么......基本上它只会覆盖任何内容（如果有的话） 在那儿。
在他们的架构中，他们对任何给定的（散列）密钥都有一个主（协调）节点的概念，他们总是先写，然后再复制到环上的其他节点，这允许他们覆盖/清除任何先前版本的值。我猜他们正在将此比较作为 CAS 或其他受保护的（通过锁）操作来防止任何并发问题。当使用 BerkeleyDB 后端时，他们很可能只是在使用其内置的事务/锁定机制。鉴于此，您应该很少遇到客户端需要解决它们的冲突值/版本。
然而，根据Jay Kreps 的这篇文章，他说：
...当不同的客户端（或请求路由器）不同意特定服务器是否可用时，会出现并发版本。在一般情况下，这不会发生——每个密钥都有一个主服务器，我们总是先写入该服务器，这允许我们立即对任何旧版本进行垃圾收集。然而，在一个写入者认为主服务器已关闭而另一个写入者认为它已启动的情况下，这两个服务器可能会接受冲突写入。存储引擎必须能够保留这两个版本，直到客户端可以解决它们。
这就是InconsistencyResolver进来的地方。
当使用put()您还从以前的获取中发送版本的版本时，（主）服务器将返回一个指示该版本已过时的指示符，并且客户端将抛出一个ObsoleteVersionException. 尽管如此，在节点失败/恢复的情况下......并发版本可能在集群中，并且只有客户端可以通过InconsistencyResolver.