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