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