什么是文件上载的最大Amazon S3复制时间？

Question

背景

我们在项目中使用Amazon S3作为客户上传文件的存储空间.

出于技术原因,我们使用临时名称将文件上载到S3,然后处理其内容并在处理完文件后重命名该文件.

问题

虽然重命名404 (key not found)的文件已成功上传,但"重命名"操作会一次又一次失败并出错.

亚马逊文档提到了这个问题:

Amazon S3通过在亚马逊数据中心内的多个服务器上复制数据来实现高可用性.如果PUT请求成功,则会安全地存储您的数据.但是,有关更改的信息必须在Amazon S3上复制,这可能需要一些时间,因此您可能会观察到以下行为:

我们实现了一种轮询作为解决方法:重试"重命名"操作,直到成功为止.
投票在20秒后停止.

此解决方法适用于大多数情况:文件在几秒钟内复制.
但有时 - 很少 - 20秒是不够的; S3中的复制需要更多时间.

问题

• 在Amazon S3上成功进行PUT操作和完全复制之间观察到的最长时间是多少？

• Amazon S3是否提供了"绕过"复制的方法？(直接查询'master'？)

Answer 1

更新:这个答案使用了一些旧的术语,我将其留在原地,大部分时间.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区域命名惯例保持一致.

- https://aws.amazon.com/s3/faqs/#regions

使用S3传输加速功能的存储桶使用全局式端点,${bucketname}.s3-accelerate.amazonaws.com并且关于us-east-1存储桶和最终一致性,此端点的行为方式尚不明显,但有理由认为其他区域不应受到影响此功能,如果启用.此功能通过将请求路由到相同的S3端点,但通过AWS"边缘网络"(与支持CloudFront相同的系统)进行代理,从而提高了远离存储桶的用户的传输吞吐量.它本质上是一个通过CloudFront的自配置路径,但没有启用缓存.加速来自优化的网络堆栈,并保持托管AWS网络上的流量,以实现其在Internet上的大部分路径.因此,如果您在存储桶上启用并使用它,此功能应该对一致性没有影响...但是,正如我所提到的,它与us-east-1存储桶的交互方式还不得而知.

美国标准(us-east-1)区域是S3中最古老的,可能是最大的区域,并且确实遵循一些不同于其他新区域的规则.

一致性模型是一个重要且相关的差异.

[美国标准以外的所有区域]中的Amazon S3存储桶为新对象的PUTS提供了读写后一致性,并为覆盖PUTS和DELETES提供了最终一致性.美国标准区域中的Amazon S3存储桶提供最终一致性.

http://aws.amazon.com/s3/faqs/

这就是为什么我认为你使用美国标准.您描述的行为与该设计约束一致.

您应该能够验证在另一个区域中的测试存储桶不会发生这种情况......但是,由于在同一区域内从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]开始,美国标准区域现在支持使用Northern Virginia端点(s3-external-1.amazonaws.com)添加到Amazon S3的新对象的读写后一致性.通过此更改,所有Amazon S3区域现在都支持读写后一致性.写入后读取一致性允许您在Amazon S3中创建后立即检索对象.在此更改之前,美国标准区域中的Amazon S3存储桶为新创建的对象提供了最终一致性,这意味着在新对象上载后可能无法立即读取一些小对象.这些偶然的延迟可能使数据处理工作流程复杂化,其中应用程序需要在创建对象后立即读取对象.请注意,在美国标准区域,此一致性更改适用于Northern Virginia端点(s3-external-1.amazonaws.com).使用全局端点(s3.amazonaws.com)的客户应切换到使用Northern Virginia端点(s3-external-1.amazonaws.com),以便利用美国标准区域中此写后读写一致性的好处. _{[强调补充]}

https://forums.aws.amazon.com/ann.jspa?annID=3112

如果要上传大量文件(每秒数百个),您可能也会压倒S3的分片机制.对于每秒非常高的上传次数,重要的是您的密钥("文件名")不是词法上的顺序.

根据亚马逊处理DNS的方式,如果您的代码可以处理它,您可能还想尝试另一种解决您的存储桶的备用变体.

可以使用http://mybucket.s3.amazonaws.com/key ...或http://s3.amazonaws.com/mybucket/key ... 来解决美国标准中的桶问题以及这两个问题的内部实施至少在理论上,可能会以一种与您的问题相关的方式改变行为的方式不同.