使用DynamoDB，两个独立的客户端尝试使用条件写入同时写入同一项目，并尝试更改条件引用的值。显然，其中一个写入注定要通过条件检查失败;没关系。
假设在写入操作期间发生了一些不好的事情，并且一些不同的DynamoDB节点失败或失去了彼此的连接。我的写作操作会怎样？
它们会阻塞还是失败（在CAP定理中牺牲“A”）？他们俩似乎都会成功吗？事后才发现他们中的一个实际上被忽略了（牺牲了“C”）？或者，由于DynamoDB系统中存在一些魔法（一致性散列？），它们是否会以某种方式正常工作？
这似乎是一个非常难的问题，但我找不到任何讨论条件写入可用性问题的可能性（例如，与一致读取不同，其中可用性降低的可能性是明确的）。
答案 0 :(得分：11)
该领域缺乏明确的信息，但我们可以做出一些非常有力的推论。许多人认为DynamoDB实现了其前身＆＃34; Dynamo＆＃34;的所有想法，但似乎并非如此，重要的是要将两者分开。亚马逊在Dynamo Paper中仔细描述了最初的Dynamo系统。考虑到这些，如果您熟悉基于Dynamo思想的分布式数据库（如Riak和Cassandra），也会很有帮助。尤其是Apache Cassandra，它提供了与CAP相关的全方位权衡。
通过将明确分布的DynamoDB与Cassandra中可用的选项进行比较，我认为我们可以看到它在CAP空间中的位置。据亚马逊＆＃34; DynamoDB维护每个项目的多个副本以确保持久性。当您收到成功的＆＃39;对您的写入请求的响应，DynamoDB确保在多个服务器上写入是持久的。但是，更新传播到所有副本需要一些时间。＆＃34; （Data Read and Consistency Considerations）。此外，DynamoDB不要求应用程序像Dynamo那样进行冲突解决。假设他们想提供尽可能多的可用性，因为他们说他们正在写多个服务器，DyanmoDB中的写入等同于Cassandra QUORUM级别。此外，似乎DynamoDB不支持hinted handoff，因为这可能导致需要解决冲突的情况。为了获得最大可用性，不一致的读取只需要等同于Cassandras的ONE级别。但是，为了获得一致的读取，鉴于仲裁写入将需要QUORUM级别读取（在R + W> N之后为了一致性）。有关Cassandra级别的更多信息，请参阅About Data Consistency in Cassandra。
总之，我的结论是：
因此，写入具有与一致读取相同的可用性。
要专门解决有关两个同时条件写入的问题，一个或两个将失败，具体取决于有多少节点关闭。但是，永远不会有不一致。写作的可用性实际上与我认为它们是否有条件无关。