s3并发写入

Question

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

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

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

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

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

亚马逊S3在美国西部(俄勒冈州),美国西部(北加州),欧盟(爱尔兰),亚太地区(新加坡),亚太地区(东京),亚太地区(悉尼)和南美洲(圣保罗)地区提供阅读 - 新对象的PUTS的写后一致性以及覆盖PUTS和DELETES的最终一致性.美国标准区域中的Amazon S3存储桶提供最终一致性.

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

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

Answer 1

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

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

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

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