AWS S3 - 减速：请降低您的请求率

Question

在 SO 上有足够多的类似问题和答案。但是很少提及前缀。 首先，不再需要前缀随机化，参见here

此 S3 请求率性能提升消除了之前的任何 指导随机化对象前缀以实现更快的性能。 这意味着您现在可以在 S3 中使用逻辑或顺序命名模式 对象命名没有任何性能影响。

现在回到我的问题。我仍然得到“减速”，我不明白为什么。
我所有的对象分布如下：

/foo/bar/baz/node_1/folder1/file1.bin
/foo/bar/baz/node_1/folder1/file2.bin
/foo/bar/baz/node_1/folder2/file1.bin
/foo/bar/baz/node_2/folder1/file1.bin
/foo/bar/baz/node_2/folder1/file2.bin

每个节点都有自己的前缀，然后是“文件夹”名称，然后是“文件”名称。每个“文件夹”中大约有 40 个“文件”。假设我有大约 20 个节点，每个节点下大约有 200 个“文件夹”，每个文件夹下有 40 个“文件”。在这种情况下，前缀由公共部分“/foo/bar/baz”、节点和文件夹组成，所以即使我并行上传所有 40 个文件，单个前缀的压力也是 40，对吧？即使我从所有节点向每个“文件夹”上传 40 个文件，每个前缀的压力仍然是 40 个。那是对的吗？如果是，我怎么会得到“减速”？如果没有我应该如何照顾它？自定义RetryStrategy?采用指数退避的DefaultRetryStrategy 怎么解决不了这个问题？

EDIT001： Here前缀是什么意思的解释

Answer 1

好的，在 S3 工程团队的帮助下与 AWS 支持团队合作了一个月后，简短的回答是，以老式方式随机化前缀。 长答案，他们确实提高了 S3 的性能，如原始问题的链接中所述，但是，您总是可以让 S3 屈服。关键是它们在内部对存储在存储桶中的所有对象进行分区，分区对存储桶前缀起作用，并且按照前缀的字典顺序对其进行组织，因此，无论如何，当您将大量文件放在不同的“文件夹”中时，它仍然对前缀的外部施加压力，然后它尝试对外部进行分区，这就是您将获得“SlowDown”的时刻。好吧，您可以通过重试以指数方式后退，但在我的情况下，5 分钟后退并没有成功，那么最后的手段是在前缀前面加上一些随机标记，理想情况下是均匀分布的。而已。 在不太激进的情况下，S3 工程团队可以检查您的使用情况并手动分区您的存储桶（在存储桶级别完成）。在我们的情况下不起作用。

不，没有钱可以为每个前缀购买更多请求，因为，我猜没有实体可以支付亚马逊重写 S3 后端的费用。

2020 更新：好吧，在为 S3 前缀实现随机化之后，我只能说一件事，如果你努力尝试，没有随机化会有所帮助。我们仍然收到SlowDown，但没有以前那么频繁了。除了重新安排失败的操作以供以后执行之外，没有其他方法可以解决此问题。

另一个 2020 年更新：呵呵，您对存储桶执行的 LIST 请求数量使我们无法正确分区存储桶。哈哈