存储桶版本控制如何影响 S3 的 read-after-write 一致性保证？

Question

虽然 S3 支持新创建对象的“先读后写”一致性，但我想了解存储桶版本控制如何影响一致性保证 - 特别是在使用键 和 访问文档时一个版本。

以下是我目前从 AWS 官方文档中收集的对 S3 提供的一致性保证的理解：

put (new) then get       = strong (with one caveat; see below)
put (overwrite) then get = eventual
put then list            = eventual
delete                   = eventual

很明显，当覆盖现有的桶版本控制对象（无论）时，当我单独通过键访问对象时，我将获得最终一致的结果。但是如果我通过键和版本访问对象，会发生什么？是否有任何指向已定义行为的 AWS 文档？

我的问题与this question 高度相关，但有一个例外：来自以下警告的负缓存概念。 AWS docs state（强调我的）：

Amazon S3 为新的 PUTS 提供写后读一致性 所有区域的 S3 存储桶中的对象，但有一个警告。 警告 是如果您对键名发出 HEAD 或 GET 请求（查找是否 对象存在）在创建对象之前，Amazon S3 提供 写后读的最终一致性。

当我从位于 key@version 的 S3 请求一个不存在的对象时，我创建/放置该对象，然后立即发出对同一 key@version 的请求，这是什么行为？

Answer 1

默认情况下，Amazon S3 将在上传具有相同文件名的新对象时替换对象。当Amazon S3 versioning 被激活时，即使文件被覆盖或删除，S3 也会保留文件的所有版本。

文件的特定版本通过 Key 和 Version-Id 的组合来引用。事实上，在打开版本控制的情况下上传文件后，就会立即分配版本 ID。

当上传具有相同文件名的文件时（从而创建对象的最新“版本”），之前的版本会保留最初分配的 Version-Id。

示例版本 ID 为：SnZzeMEz3ngtfBYWc53f_Juuzk5epXkG

您的问题是：“当我从位于 key@version 的 S3 请求一个不存在的对象时”。但是，鉴于 Version-Id 的随机性，不可能请求对象的不存在版本，然后期望下一次上传创建具有预测 Version-Id 的版本。

相反，可以这样想：创建对象的一个​​版本时，它保持相同的 Version-Id。因此，没有更新版本，因此一致性将不相关。唯一的变化是默认的“当前版本”会发生变化，因此在更新对象后检索对象可能会受到最终一致性的影响。