Amazon dynamodb DynamoDB：条件写与CAP定理

使用DynamoDB，两个独立的客户端尝试同时写入同一项，使用条件写入，并尝试更改条件引用的值。显然，其中一个写操作注定会在条件检查中失败；没关系

假设在写操作过程中，发生了一些不好的情况，一些DynamoDB节点发生故障或失去彼此的连接。我的写操作会发生什么变化

它们都会阻止还是失败（牺牲CAP定理中的“A”？他们两个看起来都成功了，只是后来发现其中一个被忽略了（牺牲了“C”）？或者，由于DynamoDB系统中的一些魔力（一致性散列？），它们是否都能正常工作

---

这似乎是一个很难解决的问题，但我找不到任何东西讨论条件写入的可用性问题的可能性（与一致读取不同，例如，一致读取的可用性降低的可能性是明确的）这方面缺乏明确的信息，但我们可以做出一些非常有力的推论。许多人认为DynamoDB实现了其前身“Dynamo”中的所有思想，但事实似乎并非如此，在您的头脑中保持这两个概念的分离是很重要的。最初的Dynamo系统由Amazon在上一篇文章中仔细描述。在考虑这些问题时，如果您熟悉基于Dynamo思想的分布式数据库，比如Riak和Cassandra，这也会很有帮助。特别是，它提供了有关CAP的一系列权衡

通过比较DynamoDB和Cassandra提供的选项，我认为我们可以看到它在CAP空间中的位置。根据Amazon的说法，“DynamoDB维护每个项目的多个副本以确保持久性。当您收到写入请求的“操作成功”响应时，DynamoDB确保写入在多个服务器上是持久的。但是，更新传播到所有副本需要时间。”（）。此外，DynamoDB不需要应用程序像Dynamo那样进行冲突解决。假设他们希望提供尽可能多的可用性，因为他们说他们正在向多个服务器写入数据，那么DyanmoDB中的写入相当于Cassandra

QUORUM

level。此外，DynamoDB似乎不支持，因为这可能导致需要解决冲突的情况。为了获得最大的可用性，不一致的读取只需要与Cassandras的

ONE

级别相当。但是，要在给定仲裁写入的情况下获得一致的读取，需要

quorum

级别的读取（在R+W>N之后进行一致性）。有关Cassandra中级别的更多信息，请参阅

总之，我的结论是：

• 写操作是“仲裁”操作，因此，要使写操作成功，行复制到的大多数节点都必须可用
• 不一致的读取是“一”，因此只有一个具有该行的节点可用，但返回的数据可能已过期
• 一致性读取是“仲裁”，因此该行复制到的大多数节点必须可用，才能成功读取

因此，写入与一致读取具有相同的可用性

为了具体解决您关于两次同时条件写入的问题，一次或两次写入都将失败，具体取决于有多少节点处于关闭状态。然而，永远不会有不一致。我认为，写操作的可用性实际上与它们是否有条件无关