我认为我在并发 s3 写入时遇到了问题。两个（或更多）进程同时将几乎相同的内容写入同一个 s3 位置。我想确定控制这种情况如何发展的并发规则。
按照设计，在写入 s3 时，除一个之外的所有进程都会被杀死。（我说过他们正在写“几乎”相同的内容，因为除了一个进程之外的所有进程都被杀死了。如果所有进程都被允许生存，他们最终会写出完全相同的内容。）
我的理论是，被杀死的进程在 s3 上留下了一个不完整的文件，而另一个文件（可能是完整编写的）没有被选为在 s3 上存在的文件。我想证明或反驳这个理论。（我试图找出问题是否是由写入 s3 期间的并发问题或其他时间引起的）。
来自http://aws.amazon.com/s3/faqs/的常见问题解答：
问：Amazon S3 采用什么数据一致性模型？
美国西部（俄勒冈）、美国西部（加利福尼亚北部）、欧洲（爱尔兰）、亚太地区（新加坡）、亚太地区（东京）、亚太地区（悉尼）和南美洲（圣保罗）区域的 Amazon S3 存储桶提供读取- 新对象的 PUTS 写入后一致性和覆盖 PUTS 和 DELETES 的最终一致性。美国标准区域中的 Amazon S3 存储桶提供最终一致性。
我使用的是美国标准区域。
- 这个答案对并发写入有什么看法？我想我理解“写后读一致性”与“最终一致性”之间的区别，但仅限于在写入完成后读取对象时所看到的上下文。
- 被杀死的进程是否有可能“获胜”并因此在 s3 上得到一个不完整的文件？或者，如果整个 PUT 操作完成，s3 是否以某种方式确保文件只会放在 s3 上？
- s3 如何决定哪个文件“获胜”？这是真正的问题。