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前缀含义的解释
答案 0 :(得分：0)
好吧，在AWS支持团队与S3工程团队的协助下，一个月后，简短的答案是，将旧的方式随机化。 长话短说，它们确实改善了S3的性能，如原始问题中的链接所述，但是，您始终可以使S3屈膝。关键是，它们在内部将存储分区中的所有对象分区，分区按存储分区前缀进行工作，并按前缀的字典顺序进行组织，因此，无论如何，当您将许多文件放在不同的“文件夹”中时，仍然对前缀的外部部分施加压力，然后尝试对外部部分进行分区，这是您获得“ SlowDown”的时刻。好吧，您可以成倍地增加重试次数，但就我而言，5分钟的退缩并没有解决问题，那么最后的办法是在前缀前面加上一些随机令牌，最好将令牌均匀分配。而已。 在不太积极的情况下，S3工程团队可以检查您的使用情况并手动分区存储桶（在存储桶级别完成）。在我们的案例中没有工作。
不，没有钱可以购买每个前缀更多的请求，因为我想没有实体可以向亚马逊支付重写S3后端的费用。