关于SO，有足够的类似问题和答案。但是关于前缀很少说。首先，不再需要前缀的随机化，请参见here
此S3请求率性能提高消除了以前的任何随机分配对象前缀以实现更快性能的指南。这意味着您现在可以在S3中使用逻辑或顺序命名模式对象命名，对性能没有任何影响。
现在回到我的问题。我仍然得到“ 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
每个节点都有自己的前缀，然后是“文件夹”名称，然后是“文件”名称。每个“文件夹”中大约有40个“文件”。可以说我有约20个节点，每个节点下约有200个“文件夹”，每个文件夹下有40个“文件”。在这种情况下，前缀由公用部分“ / foo / bar / baz”，节点和文件夹组成，因此即使我同时上传所有40个文件，单个前缀的压力也为40，对吗？即使我从所有节点向每个“文件夹”上载40个文件，每个前缀仍然承受40个压力。那是对的吗？如果是，我怎么得到“ SlowDown”？如果没有，我该如何照顾它？自定义RetryStrategy？为什么采用指数补偿的DefaultRetryStrategy无法解决此问题？
EDIT001：Here前缀含义的解释
好吧，在与AWS支持团队一起在S3工程团队的协助下一个月之后，简短的答案是，randomize是旧的方式。长话短说，它们确实改善了S3的性能，如原始问题中的链接所述，但是，您始终可以使S3屈膝。关键是，它们在内部将存储在存储桶中的所有对象分区，分区在存储桶前缀上进行，并且按照前缀的字典顺序进行组织，因此，无论如何，当您将大量文件放在不同的“文件夹”中时，仍然对前缀的外部部分施加压力，然后尝试对外部部分进行分区，这是您获得“ SlowDown”的时刻。好吧，您可以成倍地增加重试次数，但是在我的情况下，5分钟的退缩并没有解决问题，那么最后的办法是在前缀前面加上一些随机令牌，最好是均匀分配。而已。在不太积极的情况下，S3工程团队可以检查您的使用情况并手动分区存储桶（在存储桶级别完成）。在我们的案例中没有工作。
不，没有钱可以为每个前缀购买更多请求，因为我想没有实体可以为重写S3后端而向亚马逊付款。