虽然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的请求，是什么行为？
答案 0 :(得分：2)
默认情况下，当使用相同的文件名上传新对象时，Amazon S3将替换对象。激活Amazon S3 versioning后，即使文件被覆盖或删除，S3也会保留文件的所有版本。
通过Key和Version-Id的组合引用文件的特定版本。实际上，只要文件上传并打开版本控制，就会分配版本ID。
上传具有相同文件名的文件（从而创建对象的最新“版本”）时，先前版本保留最初分配的版本ID。
示例版本ID为：SnZzeMEz3ngtfBYWc53f_Juuzk5epXkG
您的问题是：“当我从位于key@version的S3请求不存在的对象时。但是，鉴于Version-Id的随机性，不可能请求不存在的对象版本，然后期望下一次上载创建具有预测版本ID的版本。
相反，请以这种方式考虑：创建对象的版本时，保持相同的Version-Id 。因此，版本不会更新，因此一致性不相关。唯一的变化是默认的“当前版本”将发生变化，因此在更新对象后检索对象可能会受到最终的一致性的影响。