桶版本控制如何影响S3的读写一致性保证？

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文档？

我的问题与这个问题高度相关，但有一个例外:负缓存的概念来自以下警告。AWS docs状态 (重点雷)：

亚马逊S3为所有地区的S3桶中的新对象的放置提供了读写一致性，但有一个警告。的警告是，如果您在创建对象之前发出头部或请求键名(以查找对象是否存在)，则S3为读写后的.提供了最终的一致性。

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

Answer 1

默认情况下，当一个新对象被上传到相同的文件名时，亚马逊S3将替换对象。当亚马逊S3版本控制被激活时，S3将保留文件的所有版本，即使它被覆盖或删除。

文件的特定版本通过键和版本Id的组合引用。实际上，版本Id是在文件上传后立即分配的，版本控制是打开的。

当上传具有相同文件名的文件(从而创建对象的最新“版本”)时，前一个版本保留原来分配的版本Id。

一个示例版本-Id是：SnZzeMEz3ngtfBYWc53f_Juuzk5epXkG

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

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