Concurrency s3并发写入

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

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

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

从常见问题解答：

问：AmazonS3采用什么数据一致性模型

亚马逊在美国西部（俄勒冈州），美国西部（北部） 加州）、欧盟（爱尔兰）、亚太地区（新加坡）、亚太地区 （东京）、亚太（悉尼）和南美洲（圣保罗）地区 为新对象的put和 覆盖放置和删除的最终一致性。Amazon S3存储桶 在美国标准区域，提供最终一致性

我使用的是美国标准区域

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

---

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

然而，S3中不可能有一个不完整的文件

AmazonS3从不添加部分对象；如果收到成功响应，AmazonS3会将整个对象添加到bucket中

---

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

这可以解释我们看到的奇怪问题。谢谢我的理论是，当同时将两个文件上传到同一个s3密钥时，Amazon会选择一个来“赢”。有时，它选择“不正确”，这意味着它选择了一个最终被杀死的（不完整的文件），这会导致S3密钥保持为空（没有文件最终被保存）。你是说其中一个PUT成功，但S3中没有创建任何文件吗？我不记得了。这是很久以前的事了。：）不是AWS，但如果你使用谷歌云，可以通过使用“先决条件”来避免。基本上，当您写入一个新对象时，您指定了前提条件“doesNotExist”，并且只有一个写入程序将成功，其他写入程序将收到异常。如果写入现有对象，则先决条件是该现有对象的“generationIdMatch”。AWS似乎没有很强的一致性使其成为可能。