使用DynamoDB，两个独立客户端试图同时写入同一项目，使用条件写入并试图更改条件引用的值。很明显，其中一个写入注定会失败并伴随条件检查;没关系。DynamoDB：条件写入与CAP定理
假设在写入操作过程中发生了某些不良情况，并且某些各种DynamoDB节点发生故障或失去彼此的连接。我的写操作会发生什么？
他们会阻止还是失败（在CAP定理中牺牲“A”）？他们两人是否会成功，只是后来事实证明其中一人实际上被忽略了（牺牲“C”）？或者他们会以某种方式正常工作，因为DynamoDB系统正在进行一些魔术（一致的哈希？）？这似乎是一个非常困难的问题，但我找不到任何讨论条件写入的可用性问题的可能性（与例如一致的读取，其中可用性降低的可能性是明确的）不同。
这方面缺乏明确的信息，但我们可以做出一些非常有力的推论。许多人认为DynamoDB实现了其前身“Dynamo”的所有想法，但似乎并非如此，将两者分开放置在脑海中非常重要。 Amazon的原始Dynamo系统在Dynamo Paper中进行了仔细描述。在思考这些问题时，如果您熟悉基于Dynamo想法的分布式数据库（如Riak和Cassandra），这也很有帮助。特别是Apache Cassandra，它提供了关于CAP的全面权衡。
通过比较分配给Cassandra中可用选项的DynamoDB，我认为我们可以看到它放置在CAP空间中的位置。根据Amazon的说法，“DynamoDB维护每个项目的多个副本以确保持久性，当您收到写入请求的'操作成功'响应时，DynamoDB确保写入在多台服务器上持久，但是需要花费时间来传播更新到所有副本。“ （Data Read and Consistency Considerations）。此外，DynamoDB不要求应用程序按照Dynamo的方式进行冲突解决。假设他们想提供尽可能多的可用性，因为他们说他们正在写入多个服务器，所以在DyanmoDB中写入相当于Cassandra QUORUM级别。另外，似乎DynamoDB不支持hinted handoff，因为这可能会导致需要解决冲突的情况。为了获得最大可用性，不一致的读取只需与Cassandras的等级相同即可。但是，为了获得一致的读取，如果法定写入需要QUORUM级别读取（在R + W> N之后的一致性）。有关卡桑德拉水平的更多信息，请参阅About Data Consistency in Cassandra。
综上所述，我的结论是：
因此写入具有与一致读取相同的可用性。
要专门解决您关于两个并发条件写入的问题，其中一个或两个将根据有多少个节点关闭而失败。但是，永远不会有不一致。写作的可用性实际上与它们是否有条件或我认为无关。