我从亚马逊的文档中看到，将新对象写入 S3 是写后读一致的，但更新和删除操作最终是一致的。我猜想在启用版本控制的情况下推送对象的 新版本 最终会像更新一样一致，但我找不到任何文档来确认。有人知道吗？
编辑：我的问题是关于 GET 的行为，无论是否指定了明确的版本。
我真的很喜欢我的项目的 更新 上的 read-after-write 行为，我可能只能模拟执行插入操作，但它可能更容易如果推送对象的新版本提供了所需的行为。
【问题讨论】：
GET对象——隐含的“最新”版本——没有在请求中指定versionId，对吧？
标签： amazon-web-services amazon-s3
如你所知...
问：Amazon S3 采用什么数据一致性模型？
所有区域中的 Amazon S3 存储桶为新对象的 PUTS 提供写后读一致性，并为覆盖 PUTS 和 DELETES 提供最终一致性。
...这就是关于一致性模型的官方声明的全部内容。
但是，我建议可以合理确定地推断其余部分，以及我们可以合理做出的假设，以及对 S3 内部工作原理的一些额外的一般性见解。
例如，我们知道 S3 实际上并没有将对象存储在层次结构中，但是：
Amazon S3 维护每个 AWS 区域中对象键名称的索引。对象键按字典顺序存储在索引中的多个分区中。
http://docs.aws.amazon.com/AmazonS3/latest/dev/request-rate-perf-considerations.html
这意味着 S3 至少有两个离散的主要组件，一个持久存储数据的后备存储，以及一个指向后备存储中位置的键索引。我们还知道，它们都分布在多个可用区中，因此它们都被复制了。
后备存储与索引分离这一事实并非已成定局，除非您记得存储类可以基于每个对象进行选择，这几乎必然意味着索引和数据是分开存储的。
从覆盖PUT 操作最终一致的事实，我们可以得出结论，即使在非版本化存储桶中，覆盖实际上也不是对后备存储的覆盖，而是对索引条目的覆盖对于该对象的键，并最终释放后备存储中不再被索引引用的空间。
我在这些断言中看到的含义是索引被复制，并且覆盖后读取（或删除）可能会命中尚未反映最近覆盖的索引副本......但是当读取在其本地索引中遇到“没有这样的键”条件时，系统会寻求更多资源密集型的路径来询问“主”索引（无论这在 S3 的体系结构中可能实际意味着什么），以查看这样的对象是否真的确实存在，但本地索引副本根本还没有知道它。
由于没有复制到适当的本地索引副本的新对象的第一个GET 几乎可以肯定很少发生，因此可以合理地预期 S3 的架构师会考虑到更高成本的“发现”当系统中的一个节点认为这可能是它遇到的情况时，用于改善用户体验的操作。
从所有这些中，我建议您最可能遇到的行为是：
GET 在覆盖 PUT 后在版本化对象上没有 versionId 将是最终一致的，因为服务于读取请求的节点不会遇到 No such Key 条件，因此不会遵循我在上面推测的理论成本更高的“发现”模型。
GET 带有对最新 versionId 的显式请求将在覆盖 PUT 时立即保持一致，因为读取节点可能会启动高成本策略以获取上游确认其索引是否反映了所有最新的数据，当然这里的条件是没有这样的版本，而不是没有这样的密钥。
我知道推测不是您所希望的，但没有记录的确认或经验（或者可能是一些真正令人信服的轶事）相反的证据，我怀疑这是我们能得出的最接近的结果根据有关 S3 平台的公开信息得出可信的结论。
【讨论】：
在获取操作期间指定版本 id 始终与启用版本控制的对象高度一致。
【讨论】：
我不会假设任何事情。
我要做的是从 PUT 请求中捕获 versionid（在 x-amz-version-id 标头中返回）并发出 GET（甚至更好的 HEAD）以确保对象确实被持久化并且在 S3 中可见.
【讨论】：