想象有两个客户端client1和client2，都写相同的密钥。这个key有3个replicas，分别是A、B、C。A先接收client1的请求，然后是client2'，而B接收client2的请求，然后是client1的请求。现在A和B肯定是不一致的，即使使用Vector Clock也无法解决冲突。我对吗？
如果是这样，似乎很容易在发电机中发生写入冲突。为什么有这么多基于 dynamo 设计的开源项目？
【问题讨论】：
标签： amazon-dynamodb distributed key-value distributed-system
如果您使用的是 Dynamo 并且担心竞争条件（如果您使用的是 lambda，则应该如此）
如果条件失败，您可以检查 putItem 或 updateItem 的条件
例如在 getItem 期间时间戳为 12345，添加条件时间戳必须等于 12345，但另一个进程更新它，将时间戳更改为 12346，您的 put/update 现在应该失败，例如在 java 中，您可以捕获 ConditionalCheckFailedException，您可以执行另一个 get项目，将您的更改应用到顶部，然后重新提交放置/更新
要防止新项目替换现有项目，请使用包含attribute_not_exists 函数的条件表达式，并将属性名称用作表的分区键。由于每条记录都必须包含该属性，attribute_not_exists 函数只有在不存在匹配项时才会成功。
有关 PutItem 的更多信息，请参阅 Amazon DynamoDB 开发人员指南中的使用项目。
参数： putItemRequest - 表示 PutItem 操作的输入。 回报： 服务返回的 PutItem 操作的结果。 抛出： ConditionalCheckFailedException - 无法评估操作中指定的条件。
【讨论】：
不能谈论 HBase，但我可以谈论受 Dynamo 启发的 Cassandra。
如果在 Cassandra 中发生这种情况，则最近的密钥获胜。
Cassandra 使用协调节点（可以是任何节点），接收客户端请求并将它们重新发送到所有副本节点。这意味着每个请求都有自己的时间戳。
假设 Client2 有最近的请求，比 Client1 晚几毫秒。
副本 A 接收保存的 Client1，然后接收保存在 Client1 上的 Client2，因为 Client2 是该密钥的最新信息。
副本 B 接收到 Client2，它被保存，然后是 Client1，它被拒绝，因为它的时间戳较旧。
副本 A 和 B 都有 Client2，最新信息，因此是一致的。
【讨论】：