在SO上有足够的类似问题和答案。但是关于前缀很少说。首先，不再需要前缀的随机化，请参见此处
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：这里的解释前缀是什么意思
好吧，在AWS支持团队与S3工程团队的协助下一个月之后，简短的答案是，将旧方法作为前缀。长话短说，他们确实提高了S3的性能，如原始问题中的链接所述，但是，您始终可以使S3屈膝。关键是，它们在内部将存储在存储桶中的所有对象分区，分区在存储桶前缀上进行，并且按照前缀的字典顺序进行组织，因此，无论如何，当您将大量文件放在不同的“文件夹”中时，仍然对前缀的外部部分施加压力，然后尝试对外部部分进行分区，这是您获得“ SlowDown”的时刻。好吧，您可以成倍地增加重试次数，但就我而言，5分钟的退缩并没有解决问题，那么最后的方法就是在前缀之前添加一些随机令牌，该令牌最好均匀分布。而已。在不太积极的情况下，S3工程团队可以检查您的使用情况并手动分区存储桶（在存储桶级别完成）。在我们的案例中没有工作。
不，没有钱可以购买每个前缀更多的请求，因为我想没有实体可以向亚马逊支付重写S3后端的费用。
2020年更新：嗯，在对S3前缀实施随机化之后，我只能说一件事，如果您努力尝试，那么随机化将无济于事。我们仍在获得，SlowDown但没有以前那么频繁。除了重新安排失败的操作以供以后执行之外，没有其他方法可以解决此问题。
2020年另一个更新：呵呵，您对存储桶执行的LIST请求数量使我们无法正确划分存储桶。大声笑
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句