我们在项目中使用Amazon S3作为客户端上传文件的存储。
出于技术原因，我们使用临时名称将文件上传到 S3，然后处理其内容并在处理完文件后重命名文件。
尽管被重命名的文件已成功上传，但“重命名”操作一次又一次失败并出现错误。404 (key not found)
亚马逊文档提到了这个问题：
Amazon S3 通过在 Amazon 数据中心内的多台服务器之间复制数据来实现高可用性。如果 PUT 请求成功，您的数据将被安全存储。但是，有关更改的信息必须跨 Amazon S3 复制，这可能需要一些时间，因此您可能会观察到以下行为：
我们实施了一种轮询作为解决方法：重试“重命名”操作，直到成功。
轮询在 20 秒后停止。
这种解决方法在大多数情况下都有效：文件在几秒钟内被复制。
但有时——很少——20秒是不够的。S3 中的复制需要更多时间。
您观察到在 Amazon S3 上成功执行 PUT 操作和完成复制之间的最长时间是多少？
Amazon S3 是否提供“绕过”复制的方法？（直接查询'master'？）
更新：这个答案使用了一些较旧的术语，大部分情况下我都保留了这些术语。AWS 更改了“US-Standard”的友好名称，以便与其他区域的命名更加一致，但其IPv4 的区域端点仍然具有不寻常的名称s3-external-1.amazonaws.com。
S3 的 us-east-1 区域有一个 IPv4/IPv6“双栈”端点，该端点遵循标准约定，s3.dualstack.us-east-1.amazonaws.com如果您启用了 IPv6，则该端点在操作上似乎与s3-external-1下面讨论的等效。
记录在案的对该区域请求的地理路由的引用似乎已基本消失，没有太多评论，但轶事证据表明，以下信息仍然与该区域相关。
问：没有美国标准区域吗？
我们将美国标准区域重命名为美国东部（弗吉尼亚北部）区域，以与 AWS 区域命名约定保持一致。
使用 S3 Transfer Acceleration 功能的存储桶使用全局样式的端点${bucketname}.s3-accelerate.amazonaws.com目前尚不清楚该端点在 us-east-1 存储桶和最终一致性方面的行为如何，尽管如果启用，其他区域不应受到此功能的影响。此功能通过将请求路由到相同的 S3 端点但通过 AWS“边缘网络”（为 CloudFront 提供支持的同一系统）代理，提高了距离存储桶较远的用户的传输吞吐量。它本质上是通过 CloudFront 的自我配置路径，但未启用缓存。加速来自优化的网络堆栈，并将流量保持在托管的 AWS 网络上，以确保其通过 Internet 的大部分路径。因此，如果您在存储桶上启用并使用此功能，则该功能应该不会影响一致性……但是，正如我所提到的，它如何与 us-east-1 存储桶交互尚不清楚。
US-Standard (us-east-1) 区域是 S3 中最古老、可能也是最大的区域，并且与其他较新的区域相比，它确实遵循一些不同的规则。
一个重要且相关的区别是一致性模型。
[除美国标准之外的所有区域] 中的 Amazon S3 存储桶为新对象的 PUTS 提供写后读一致性，并为覆盖 PUTS 和 DELETES 提供最终一致性。美国标准区域中的 Amazon S3 存储桶提供最终一致性。
这就是为什么我假设您使用的是美国标准。您描述的行为与该设计约束一致。
您应该能够验证在另一个区域中的测试存储桶不会发生这种情况......但是，由于在同一区域内从 EC2 到 S3 的数据传输是免费的且延迟非常低，因此使用不同区域中的存储桶可能不实用。
还有另一个值得尝试的选择，与美标的内部运作有关。
美国标准实际上在地理上分布在弗吉尼亚州和俄勒冈州之间，对“s3.amazonaws.com”的请求通过 DNS 有选择地路由到一个或另一个位置。这种路由很大程度上是一个黑匣子，但亚马逊公开了一种解决方法。
您可以通过将端点从“s3.amazonaws.com”更改为“s3-external-1.amazonaws.com”来强制将您的请求仅路由到北弗吉尼亚...
http://docs.aws.amazon.com/general/latest/gr/rande.html#s3_region
...这是我的猜测，但是您的请求的地理路由可能会加剧您的问题，并迫使他们使用“s3-external-1”（需要明确的是，这仍然是美国标准），可能会有所改善或消除您的问题。
更新：上述建议已正式超越猜测，但我将其留作历史参考。大约一年我写了上面的内容，亚马逊确实宣布 US-Standard 确实在创建新对象时提供了读写一致性，但仅限于使用s3-external-1端点时。他们将其解释为好像这是一种新行为，并且可能就是这种情况……但也可能只是平台官方支持的行为发生了变化。无论哪种方式：
从 [2015-06-19] 开始，美国标准区域现在支持使用北弗吉尼亚终端节点 (s3-external-1.amazonaws.com) 添加到 Amazon S3 的新对象的读写一致性。通过此更改，所有 Amazon S3 区域现在都支持写后读一致性。写后读一致性允许您在 Amazon S3 中创建对象后立即检索对象。在此更改之前，美国标准区域中的 Amazon S3 存储桶为新创建的对象提供最终一致性，这意味着在新对象上传后可能无法立即读取一些小对象集。这些偶尔的延迟可能会使数据处理工作流程复杂化，其中应用程序需要在创建对象后立即读取对象。请注意，在美国标准区域，此一致性更改适用于北弗吉尼亚终端节点 (s3-external-1.amazonaws.com)。使用全球终端节点 (s3.amazonaws.com) 的客户应改用北弗吉尼亚终端节点 (s3-external-1.amazonaws.com)，以便在美国标准区域利用这种先读后写一致性的优势. [重点补充]
如果您要上传大量文件（每秒数百个），您也可能会压倒 S3 的分片机制。对于每秒非常多的上传，重要的是您的键（“文件名”）不是词法顺序的。
根据 Amazon 处理 DNS 的方式，如果您的代码可以处理它，您可能还想尝试另一种寻址存储桶的变体。
US-Standard 中的存储桶可以通过http://mybucket.s3.amazonaws.com/key ... 或http://s3.amazonaws.com/mybucket/key ... 以及这两者的内部实现来解决至少在理论上，可能会有所不同，从而以与您的问题相关的方式改变行为。