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