DynamoDB 条件写入是事务性的吗？

Question

我很难理解 DDB 提供条件写入但最终保持一致的二分法。这两个事实似乎互相矛盾。

在经典场景中，用户 Bob 更新密钥 A 并将值设置为“FOO”。用户 Alice 从尚未收到更新的节点读取数据，因此它获得同一密钥的原始值“BAR”。

如果 Bob 和 Alice在没有条件检查的情况下写入集群上的不同节点，则可能会发生冲突，Alice 和 Bob 同时写入同一密钥，并且 DDB 不知道哪个更新应该是最新的。客户端必须在下次读取时解决此冲突。

但是当使用条件写入时呢？

如果 A 的现有值为“BAR”，则用户 Bob 将其对 A 的更新发送为“FOO”。如果 A 的现有值为“BAR”，则用户 Alice 将其对 A 的更新发送为“BAZ”。

在本地，每个节点都可以检查其节点是否具有原始“BAR”值并进行更新。但要了解集群中 A 的真实状态的唯一方法是首先在集群中进行强一致性读取。这种强一致性读取必须对 Alice 或 Bob 造成阻塞，或者他们可以同时进行强一致性读取。

所以这就是我对 DDB 条件写入的性质感到困惑的地方。在我看来：

1. 条件写入仅在本地进行评估。合并冲突仍然可能发生。
2. 条件写入是跨集群评估的。

如果是#2，我认为有效的唯一方法是：

1. 为钥匙创建了一把锁。
2. 进行了高度一致的读取。

假设它是#2。现在鲍勃的更新在哪里呢？更新已对节点 2 进行并发送到节点 1，并且我们拥有多数法定人数。但是为了让 Alice 在执行自己的条件写入时可以使用这些更新，需要从 WAL 中刷新这些更新。那么在条件写入中更新总是会刷新吗？一般来说，写入总是刷新吗？

SO 上还有其他类似的问题，但答案是有关此问题的 AWS 文档的重复或链接。AWS文档并没有真正解释这一点（或者我错过了）。

Answer 1

DynamoDB 条件写入是“事务性”写入，但它们的完成方式不是公开信息，并且可能是专有知识产权。

DynamoDB 开发人员是唯一掌握此信息的人。

您的问题是，您从节点的角度来看待这个问题 - 我已经浏览了DynamoDB 文档中任何地方提到的节点，它只是提到了Node .js 或 DAX节点，而不是数据库节点。

虽然可能存在过时的读取 - 是的，这表明某种形式的节点- 在执行条件写入时没有数据库节点。

如果 A 的现有值为“BAR”，则用户 Bob 将其对 A 的更新发送为“FOO”。如果 A 的现有值为“BAR”，则用户 Alice 将其对 A 的更新发送为“BAZ”。

谁的请求先到达那里，谁就最先通过。

下一个请求将失败，这意味着您现在需要发出新的读取请求以获取最新值，然后继续进行第二次写入。

Amazon DynamoDB 开发人员指南非常清楚地说明了这一点。

请注意，没有节点、副本等 - 只有 1 个对DynamoDB表的引用：

条件写入可能会跨集群进行评估，并且可能会进行强一致的读取，但亚马逊尚未公开此信息。