amazon-web-services - 在 AWS S3 中创建对象的新版本最终是一致的还是先读后写一致的？

Question

我从 Amazon 的文档中看到，将新对象写入 S3 是写后读一致的，但更新和删除操作最终是一致的。我猜想推一个 新版本打开版本控制的对象最终会像更新一样保持一致，但我找不到任何文档来确认。有人知道吗？

编辑:我的问题是关于 GET 的行为，无论是否指定了显式版本。

我真的很喜欢 上的读写行为更新 对于我的项目，我可能只能模拟执行插入操作，但如果推送对象的新版本提供所需的行为，可能会更容易。

Answer 1

正如你已经知道的...

Q: What data consistency model does Amazon S3 employ?

Amazon S3 buckets in all Regions provide read-after-write consistency for PUTS of new objects and eventual consistency for overwrite PUTS and DELETES.

— https://aws.amazon.com/s3/faqs/

...这就是关于一致性模型的官方声明的全部内容。

但是，我建议可以据此推断出剩余部分，以及我们可以合理做出的假设，以及对 S3 内部工作原理的一些额外的一般见解。

例如，我们知道 S3 实际上并没有将对象存储在层次结构中，但是:

Amazon S3 maintains an index of object key names in each AWS region. Object keys are stored lexicographically across multiple partitions in the index.

http://docs.aws.amazon.com/AmazonS3/latest/dev/request-rate-perf-considerations.html

这意味着 S3 至少有两个独立的主要组件，一个保存数据的后备存储，以及一个指向后备存储中位置的键索引。我们也知道两者都分布在多个可用区中，因此它们都被复制。

后备存储与索引分离的事实并不是已成定局，除非您记得存储类可以基于每个对象进行选择，这几乎必然意味着索引和数据是分开存储的。

从覆盖的事实 PUT操作最终是一致的，我们可以得出结论，即使在非版本化存储桶中，覆盖实际上也不是后备存储的覆盖，而是该对象键的索引条目的覆盖，并最终释放了后备存储中不再被索引引用的空间。

我在这些断言中看到的含义是索引被复制，并且有可能在覆盖后读取(或删除)命中尚未反射(reflect)最近覆盖的索引副本......但是当读取如果在其本地索引中遇到“没有这样的键”情况，系统会寻求更多资源密集型路径来询问“主”索引(无论在 S3 的架构中实际上意味着什么)，以查看这样的对象是否确实存在，但是本地索引副本还没有知道它。

自第一期 GET没有复制到适当的本地索引副本的新对象几乎肯定很少发生，可以合理地期望 S3 的架构师允许更高成本的“发现”操作以改善用户体验，当系统中的节点认为这可能是它遇到的情况。

综上所述，我建议您最有可能遇到的行为是:

GET覆盖后在版本化对象上没有 versionId PUT最终会是一致的，因为为读取请求提供服务的节点不会遇到 No such Key 条件，因此不会遵循我上面推测的理论成本较高的“发现”模型。

GET对最新 versionId 的显式请求将在覆盖时立即保持一致 PUT ，因为读取节点可能会启动高成本策略来获得上游确认其索引是否反射(reflect)了所有最新数据，当然这里的条件是没有这样的版本，而不是没有这样的 key 。

我知道猜测不是你所希望的，但没有书面确认或经验(或者可能是一些真正令人信服的轶事)相反的证据，我怀疑这是我们最接近根据公开信息得出可信结论的方法关于S3平台。