在我们的Sping Boot 应用程序中，我们使用AmazonS3Client.deleteObjects（）来删除一个桶中的多个对象。有时，请求会抛出MultiObjectDeleteException，一个或多个对象不会被删除。这种情况并不常见，在数千个请求中大约有5个失败。但这仍然可能是一个问题。什么会导致异常？
而且我也不知道怎么调试。我们应用的日志是跟着数据流走的，但没有显示太多有用的信息。它在请求后突然抛出异常。请帮助。
另一件事是异常返回一个200代码。这怎么可能呢？
异常提示：无法删除一个或多个对象（服务：null;状态代码：200;错误代码：空;请求ID：xxxx; S3扩展请求ID：yyyy;代理人：空值）
1条答案
按热度按时间uemypmqf1#
TLDR：有些错误率是正常的，应用程序应该可以行程。500和503错误是可以重试的。
MultiObjectDeleteException应该会提供提示，而getDeletedObjects()会给您已删除对象的清单。其他的您应该稍后再试。在MultiObjectDeleteException文档中，异常应该有导致错误的问题的解释
https://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/com/amazonaws/services/s3/model/MultiObjectDeleteException.html
多对象删除API部分或全部失败的异常错误，包括发生的错误。有关成功删除的对象，请参阅
getDeletedObjects()。根据https://aws.amazon.com/s3/sla/，AWS不保证100%可用性。同样，根据该文档：
·“错误率”指：（i）Amazon S3服务返回的错误状态为“InternalError”或“ServiceUnavailable”的内部服务器错误总数除以（ii）在该5分钟间隔内适用请求类型的请求总数。我们将计算每个亚马逊S3服务账户的错误率，作为每月计费周期中每个5分钟间隔的百分比。内部服务器错误数量的计算将不包括因任何Amazon S3 SLA排除条款而直接或间接产生的错误。
通常我们从停机时间的Angular 来考虑SLA，因此很容易认为AWS也是如此。但这里不是这样。一定数量的错误是正常的，应该在意料之中。在许多文档中，AWS确实建议您实施减速和重试的组合，例如这里的https://docs.aws.amazon.com/AmazonS3/latest/userguide/ErrorBestPractices.html
同样，一些500和503错误是正常操作的一部分https://aws.amazon.com/premiumsupport/knowledge-center/http-5xx-errors-s3/该文档明确指出：
由于Amazon S3是分布式服务，因此在正常使用该服务的过程中，预计5xx错误的比例非常小。所有从Amazon S3返回5xx错误的请求都可以重试。这意味着最佳做法是为向Amazon S3发出请求的任何应用程序提供容错机制或实现重试逻辑。通过这样做，S3可以从这些错误中恢复。
编辑：后来添加了一个问题：“API调用返回状态代码
200，而某些对象未被删除，这怎么可能。"**这个问题的答案很简单：**这就是API的定义。从
deleteObjects的JDK参考页面，您可以直接转到AWS API文档页面https://docs.aws.amazon.com/AmazonS3/latest/API/API_DeleteObjects.html，该页面指出这是预期行为。状态代码200表示高级API代码成功，并能够请求删除列出的对象。当然，其中一些操作确实失败了，但API调用确实在响应中创建了一个关于它的报告。同样，AWS Java SDK的作者试图将响应转换为Java编程语言，他们清楚地认为，虽然AWS API作为服务协议的一部分以非零错误率工作，但Java开发人员更习惯于这样一种情况，即任何非100%成功的事情都应该以异常结束。
这两种抽象都有很好的文档记录，程序员负责精确的实现。工程规则是便宜、快速、可靠--选择两个。AWS能够提供一种同时具备这三个方面的服务，但有一个合理的让步，即部分可靠性将在客户端实现--重试和减速。