1

在Dynamo 论文的 Section 5 中，有以下内容：

特别是，由于每次写入通常都在读取操作之后，因此写入的协调器被选择为对存储在请求的上下文信息中的先前读取操作响应最快的节点。这种优化使我们能够选择具有先前读取操作读取的数据的节点，从而增加获得“read-your-writes”一致性的机会。

获得“read-your-writes”一致性的机会如何增加？

“read-your-writes”意味着在写入之后的读取获取写入设置的值。读取和写入由两个不同的客户端为此上下文执行。原因是写入协调器的选择不会影响同一客户端获得“read-your-writes”的机会。

但是上面的文字是在谈论读取之后的写入。这是我的猜测。如果可能，读取协调器将尝试进行语法协调。如果由于版本不同而无法进行语法协调，则客户端需要在写入之前进行语义协调。无论哪种方式，读取操作中涉及的所有节点上的版本都是协调版本的祖先。因此，可以将以下写入发送给其中任何一个以进行应用。读取看到写入的最早时间是在完成以下步骤之后：

  • 客户联系写协调员。
  • 写协调器为新版本生成版本时钟。
  • 写入协调器在本地写入新版本。

执行上述步骤的时间越短，另一个后续阅读看到新版本的可能性就越大。因为很有可能对先前读取响应最快的节点可以在更短的时间内执行以下步骤。这样一个节点被选为写协调器。

4

2 回答 2

1
  1. 第 2.3 节讨论了在读取时间而不是写入时间执行协调。
  2. 数据版本控制——“通过检查它们的矢量时钟，可以确定一个对象的两个版本是在并行分支上还是具有因果顺序。”
  3. 本段来自第 4 节。[强调我的]

在 Dynamo 中，当客户端希望更新对象时，它必须指定要更新的版本。这是通过传递从较早的读取操作中获得的上下文来完成的，其中包含矢量时钟信息。在处理读取请求时，如果 Dynamo 可以访问多个无法在语法上协调的分支，它将返回叶子中的所有对象，并在上下文中包含相应的版本信息。使用此上下文的更新被认为已经协调了不同的版本，并且分支被折叠成一个新版本

因此，通过先执行读取，您可以在写入之前有效地协调所有不同的版本。通过写入同一个节点，您更新的版本会被标记为最新版本的上下文和矢量时钟，并且所有不同的分支都可以折叠。这会尽快发送到前 N 个节点（如您所说）。但是通过删除不同的分支 - 您可以减少返回多个值的机会。你只需要一个N 个节点中的 N 个节点在下一次读取中读取以获得协调的写入。即 - 作为 R 法定人数的一部分的节点说 - “我是和解的版本，所有其他人都必须向我鞠躬”。（如果已经分发到另一个“R”节点，那么在仲裁中获得协调版本的机会就更大了）

但是，如果您写入另一个节点，一个您没有从中读取的节点 - 正在更新的矢量时钟可能不一定是对象的协调版本。因此，您仍然可以有不同的分支。下面的阅读将尝试协调它，但更有可能的是您可能有多个不同的数据并且没有协调。

如果你已经做到了这一步，我认为最有趣的部分是，根据第 6 节，客户端应用程序可以指定 N、R 和 W 的值——即——构成要从中提取的池的节点数，以及数量必须同意读取或写入才能成功的节点数。

哎呀——我现在头疼。

于 2013-08-07T03:30:59.863 回答
1

我重新阅读了 Dynamo 论文。我对“read-your-write”一致性有了新的理解。“read-your-writes”只涉及一个客户。想象一下一个客户端在同一个键上执行的以下请求：

  1. 读一
  2. 写一
  3. 读取 2

“read-your-writes”意味着 read-2 看到 write-1。write coordinator 最有可能拥有 write-1。为了确保“read-your-writes”，希望写协调器对 read-2 的回复最快。很有可能该节点对 read-1 的响应速度最快，而对 read-2 的响应速度也最快。所以选择对read-1回复最快的节点作为写协调器。

什么是the node that replied fastest to the previous read operation？只有在使用客户端驱动的协调时，这样的节点才有意义。对于服务器端协调，协调节点回复客户端，其他相关节点回复协调节点。replied fastest在这种情况下是没有意义的。

于 2014-08-12T08:06:39.400 回答