s3并发写入

Question

我认为我遇到了并发s3写入的问题。两个（或更多）进程正在同时将几乎相同的内容写入同一个s3位置。我想确定控制这种情况将如何发挥作用的并发规则。

按照设计，在写入s3时，所有进程都会被杀死。 （我曾说他们写的“几乎”是相同的内容，因为除了其中一个进程之外，所有进程都被杀死。如果所有进程都被允许生存，他们最终会写出相同的内容。）

我的理论是，被杀的过程是在s3上留下一个不完整的文件，另一个文件（可能是完全写的）并没有被选为s3上的文件。我想证明或反驳这一理论。 （我试图找出问题是否是在写入s3期间或其他时间由并发问题引起的。）

来自http://aws.amazon.com/s3/faqs/的常见问题解答：

  

问：Amazon S3采用什么数据一致性模型？

     

亚马逊S3在美国西部（俄勒冈州），美国西部（北部）   加州），欧盟（爱尔兰），亚太（新加坡），亚太地区   （东京），亚太（悉尼）和南美（圣保罗）地区   为新对象的PUTS提供读写后一致性   覆盖PUTS和DELETES的最终一致性。亚马逊S3桶   在美国标准区域提供最终的一致性。

我正在使用美国标准区域。

• 这个答案对并发写入有什么看法？我想我理解“读后写一致性”与“最终一致性”之间的区别，但仅限于在写完成后读取对象时所看到的内容。
• 被杀死的进程是否有可能“赢”并因此在s3上以不完整的文件结束？或者，如果整个PUT操作完成，s3会以某种方式确保文件只放在s3上吗？
• s3如何决定哪个文件“获胜”？这是真正的问题。

Answer 1

我认为该FAQ条目中的一致性声明并未说明在同一个密钥的并发写入期间会发生什么。

但是，S3中不可能有一个不完整的文件：http://docs.aws.amazon.com/AmazonS3/latest/API/RESTObjectPUT.html说

  

Amazon S3从不添加部分对象;如果您收到成功响应，Amazon S3会将整个对象添加到存储桶中。

这意味着只有完全上传的文件才会存在于指定的密钥中，但我认为这样的并发写入可能会导致某些错误情况导致无法成功上载文件。我会做一些测试以确定;您可能还希望尝试使用对象版本控制，并查看其行为是否有所不同。