amazon-web-services - AWS S3 - 减速 : Please reduce your request rate

Question

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

This S3 request rate performance increase removes any previous guidance to randomize object prefixes to achieve faster performance. That means you can now use logical or sequential naming patterns in S3 object naming without any performance implications.

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

/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

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

编辑001:
Here前缀是什么意思的解释

Answer 1

好的，在 S3 工程团队的协助下与 AWS 支持团队合作一个月后，简短的回答是，以旧方式随机化前缀。
答案很长，正如原始问题中的链接所述，它们确实提高了 S3 的性能，但是，您始终可以使 S3 屈服。关键是它们在内部对存储在存储桶中的所有对象进行分区，分区对存储桶前缀起作用，并按照前缀的字典顺序进行组织，因此，无论如何，当您将大量文件放在不同的“文件夹”中时仍然对前缀的外部施加压力，然后它会尝试对外部进行分区，这就是您将获得“SlowDown”的时刻。好吧，您可以通过重试以指数方式回退，但在我的情况下，5 分钟的回退并没有成功，那么最后的方法是在前缀前面加上一些随机标记，理想情况下是均匀分布的。就是这样。
在不太激进的情况下，S3 工程团队可以检查您的使用情况并手动分区您的存储桶(在存储桶级别完成)。在我们的情况下不起作用。
不，没有钱可以购买每个前缀的更多请求，因为我想没有实体可以向亚马逊支付重写 S3 后端的费用。
2020 年更新:好吧，在对 S3 前缀实现随机化之后，我只能说一件事，如果你努力尝试，没有任何随机化会有所帮助。我们还在收到 SlowDown但没有以前那么频繁了。除了重新安排失败的操作以供以后执行之外，没有其他方法可以解决此问题。
另一个 2020 年更新:嘿嘿，您对存储桶执行的 LIST 请求数量阻止了我们对存储桶进行正确分区。哈哈