哪些HTTP错误永远不会触发自动重试？

Question

我正在尝试使一些微服务更具弹性,并且重试某些类型的HTTP请求将有助于此.

重试超时会给客户带来非常缓慢的体验,因此我不打算在这种情况下重试.重试400s无济于事,因为错误的请求在几毫秒后仍然是一个错误的请求.

我想还有其他原因不能重试一些其他类型的错误,但是哪些错误以及为什么？

Answer 1

有一些错误不应该重试,因为它们似乎是永久性的:

因此,不应重试大多数4**Client错误.

不应重试的5**Servers错误:

但是,为了使微服务更具弹性,您应该使用断路器模式,并在上游关闭时快速失败.

500 可以是服务器上的任何内容，例如在下次重试时会消失的数据库通信故障。我会重试 500 (21认同)
@cahen从我看到的,编程错误报告为500.你认为修补BUG的速度有多快？300ms的？:)这取决于启发式.RFC 2616表示条件(临时与永久)应包含在响应中:`服务器应该包含一个实体,其中包含对错误情况的解释,以及它是暂时的还是永久的条件. (2认同)

Answer 2

4xx 代码表示调用方发生了错误。这可能是错误的 URL、错误的身份验证凭据或任何表明这是错误请求的内容。因此，如果不解决该问题，就不会使用重试。错误在调用者的域中，调用者应该修复它，而不是希望它会自行修复。

有例外。让我们假设正在重新部署或重新启动服务。在那种情况下，没有注册端点，因此将发送 4xx http 代码。但是，稍等片刻，服务器就可以使用了。因此，重试似乎是有益的。

更深入的分析将表明服务在重新启动时应该是滚动重新启动以防止中断。因此，先前的论点不再成立。但是，如果您的环境/生态系统没有遵循这种做法，并且由于上述原因，您认为客户端报告的错误（4xx 代码）值得重试，那么您可以选择这样做；但是成熟的系统不会这样做，因为没有感知到的好处并且失去了快速失败的能力。

应重试 5xx 错误代码，因为它们是服务错误。它们可能是短期的（线程溢出、依赖服务拒绝连接）或长期（系统缺陷、依赖系统中断、基础设施不可用）。有时，服务会回复信息（通常是标题），无论这是永久的还是临时的；有时还有关于何时重试的时间参数。根据这些参数，调用者可以选择是否重试。

出于显而易见的原因，不需要重试 1xx、2xx 和 3xx 代码。

这些概括似乎并不适用于所有情况。我可以看到 408（超时）或 409（冲突）和 429（请求过多）如何可重试，而其他 400 级错误似乎不可重试。我还可以看到 100 级如何期待另一个请求，大多数 300 级也是如此。也许这些不是重试，但它们也不是错误......并且大多数 500 级不应该重试。在 5xx 范围内，我想我只会重试 500（内部服务器错误）、502（网关错误）、503（服务不可用）、504（网关超时）和 599（网络连接超时错误）。 (3认同)