有没有人达到过读取或写入Amazon S3存储桶的上限？

Question

是否存在S3缩放的已知限制？有没有人有这么多的同时读取或写入,桶开始返回错误？我对写入比读取更感兴趣,因为S3可能会针对读取进行优化.

Answer 1

Eric 的评论已经在概念层面上进行了总结，如常见问题解答中所述，如果我的应用程序的流量突然激增，会发生什么情况？还有：

\n\n

\n

Amazon S3 专为处理任何 Internet 应用程序的流量而设计。Amazon S3\xe2\x80\x99 的大规模使我们能够均匀分布负载，因此任何单个应用程序都不会受到流量峰值的影响。

\n

\n\n

当然，您仍然需要考虑可能的问题并针对重复的减速错误调整[您的]应用程序（请参阅Amazon S3 错误最佳实践）：

\n\n

\n

与任何分布式系统一样，S3 具有保护机制，可以检测有意或无意的资源过度消耗并做出相应反应。当高请求率触发这些机制之一时，可能会出现 SlowDown 错误。降低请求率将减少或消除此类错误。一般来说，大多数用户不会经常遇到这些错误；但是，如果您\n 想了解更多信息或遇到严重或意外的\n SlowDown 错误，请发布到我们的 Amazon S3 开发人员论坛\n http://developer.amazonwebservices.com/connect/forum.jspa?forumID=24 \n 或注册 AWS 高级支持\n http://aws.amazon.com/premiumsupport/。[强调我的]

\n

\n\n

虽然这种情况很少见，但确实会发生 - 以下是AWS 团队的回复，说明了该问题（虽然相当过时）：

\n\n

\n

当请求率足够高时，Amazon S3 将返回此错误，\n 为请求提供服务会导致其他客户的服务质量下降。此错误很少被触发。 如果您确实收到了它，您应该以指数方式退缩。如果发生此错误，系统资源将被被动地重新平衡/分配，以更好地支持更高的请求率。因此，抛出此错误的时间段应该相对较短。[强调我的]

\n

\n\n

您关于读取与写入优化的假设也得到了证实：

\n\n

\n

触发此错误的阈值各不相同，并且部分取决于请求类型和模式。一般来说，您将能够\n 通过gets 与puts 以及通过少量键的大量gets 与大量键的大量gets 获得更高的rps。\n 当获取或放置大量密钥时，如果密钥按字母数字顺序与随机/散列顺序\n 相比，您将能够获得\n 更高的 rps。

\n

\n