amazon-web-services - DynamoDB 条件写入是事务性的吗？

Question

我无法围绕 DDB 提供条件写入的二分法，但也最终保持一致。这两个真理似乎相互矛盾。
在经典场景中，用户 Bob 更新 key A 并将值设置为“FOO”。用户 Alice 从尚未收到更新的节点读取数据，因此它获得了相同 key 的原始值“BAR”。

如果 Bob 和 Alice 在没有条件检查的情况下写入集群上的不同节点，则可能会发生冲突，即 Alice 和 Bob 同时写入相同的 key ，而 DDB 不知道哪个更新应该是最新的。客户端必须在下次读取时解决此冲突。
但是什么时候使用条件写入呢？
如果 A 的现有值为“BAR”，则用户 Bob 将其对 A 的更新发送为“FOO”。
如果 A 的现有值为“BAR”，则用户 Alice 将其对 A 的更新发送为“BAZ”。

在本地，每个节点都可以检查其节点是否具有原始“BAR”值并进行更新。但是，了解 A 在整个集群中的真实状态的唯一方法是首先在整个集群中进行强一致性读取。对于 Alice 或 Bob 来说，这种强一致性读取必须是阻塞的，或者他们可以同时进行强一致性读取。
所以这里是我对 DDB 条件写入的性质感到困惑的地方。在我看来，要么:

条件写入仅在本地进行评估。合并冲突仍然可能发生。

条件写入是跨集群评估的。

如果它是#2，我认为工作的唯一方法是:

为 key 创建了一个锁。

进行强一致性读取。

假设它是#2。现在鲍勃的更新在哪里？对节点 2 进行了更新并发送到节点 1，我们有一个多数法定人数。但是为了在 Alice 执行自己的条件写入时使这些更新可用，这些更新需要从 WAL 中刷新。那么在条件写入中，更新总是被刷新吗？写入是否总是刷新？
在 SO 上还有其他类似的问题，但答案是关于此的 AWS 文档的重复或链接。 AWS 文档并没有真正解释这一点(或者我错过了)。

Answer 1

DynamoDB 条件写入是“事务性”写入，但它们的完成方式不是公开信息，也许是专有知识产权。
DynamoDB 开发人员是唯一掌握此信息的人员。

你的问题是你是从节点的角度来看这个的 - 我已经经历了 every mention of node anywhere in DynamoDB documentation &它只是提到节点 .js 或 DAX 节点 s 不是数据库节点。
虽然可能有过时的读取 - 是的，这表明某种形式的节点 - 在进行条件写入时没有数据库节点。

User Bob sends their update for A as "FOO" if the existing value for A is "BAR". User Alice sends their update for A as "BAZ" if the existing value for A is "BAR".

谁的请求第一个到达那里，就是第一个通过的人。
下一个请求将失败，这意味着您现在需要发出一个新的读取请求以获取最新值，然后再进行第二次写入。
Amazon DynamoDB developer guide 非常清楚地表明了这一点。
请注意，没有节点、副本等 - 只有 1 个对 DynamoDB 表的引用:


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