重试模式，如何确定PHP中的失败类型

我想在PHP（Guzzle）中实现重试模式，以确定是否需要在失败的情况下再次发送请求。如果我需要，我是否应该在再次发送之前使用一些延迟。注意：这是内部服务通信，每个服务都在扩展组中，在负载平衡器后面，因此我们假设目标URL是现有URL，但可能由于某些原因不可用，而且所有服务器都是NGINX

对于是否执行重试以及是否延迟，是否有最佳做法？？

据我所知，status

503

意味着服务器过载，因此在这种情况下，小延迟可能有助于等待新实例启动并帮助分配负载

如果出现

502/504

错误，该怎么办？还要延迟重试

如果出现

500

错误，该怎么办？？根据我的理解，当服务器或逻辑出现问题，并且我们不需要执行任何重试时，应该抛出

500

那么

400

，就像我们得到

500

一样的动作呢

那么

404

呢？？可以有两种类型的

404

，一种是端点确实不存在（我认为在内部服务之间通信的情况下不可能），另一种是未找到请求的资源（例如，未通过凭据找到用户）。我认为在

404

的情况下，我们不需要执行重试

422

我在出现域错误或验证错误时使用，但在其他情况下，服务器可能会返回它？如果它只是由我触发的，我可以假设不需要重试

其他状态代码如何，是否也有NGINX特定代码

---

我知道我可能需要针对每个URI案例制定一个特定的重试策略，但我相信有一些通用/可重用的规则。

我最终得到了这样的列表：

• 400错误请求-无重试
• 401未经授权-无重试
• 402需要付款-无需重试
• 403禁止-不重试
• 404找不到-正如我之前所说，我假设我们有不同的404，如果没有找到一些资源，比如数据库中的用户，如果404页面在URL错误的情况下没有找到，并且没有找到b-z平衡问题。因此，如果找不到某些资源，我们将发送一些自定义数据，在这种情况下不重试，在其他情况下，我们将重试
• 405不允许使用方法-不重试
• 406不可接受-无重试
• 407需要代理身份验证-无需重试
• 408请求超时-重试
• 409冲突-重试
• 410消失-无重试
• 411所需长度-无需重试
• 412前提条件失败-无重试
• 413有效负载太大-无重试
• 414 URI太长-无重试
• 415不支持的媒体类型-无重试
• 416范围不可满足-无重试
• 417预期失败-没有重试
• 421定向错误的请求-无重试
• 422不可处理实体-无重试
• 423已锁定-如果指定的锁定时间和时间不太长，请重试
• 424依赖项失败-无重试
• 426需要升级-无需重试
• 需要428前置条件-无需重试
• 429请求太多-可能重试重试
• 431请求标头字段TooLarge-无重试
• 451因法律原因不可用-无重试

因此，大多数4**客户端错误不应重试

不应重试的5**服务器错误：

• 500内部服务器错误-不重试，在大多数情况下不会捕获应用程序错误，因此我们不应该重试
• 501未实现-无重试
• 502坏网关-重试
• 503服务不可用-重试
• 504网关超时重试
• 505 HTTP版本不受支持-无重试
• 506变体也进行协商-无重试
• 507存储不足-无重试
• 检测到508循环-没有重试
• 510未扩展-无重试
• 511需要网络身份验证-无重试

---

这一个将转到基本重试策略，但正如我所说的，每个请求都应该单独处理，因此大多数请求都有自己的策略，覆盖一些代码处理并使用不同的重试时间。

这一切都很好，完全可以根据HTTP状态代码来确定是否重试请求。但是，这确实假设那些开发您试图与之通信的应用程序的人在每个给定情况下都使用了正确的状态代码。我倾向于以指数增长的间隔对每个请求重试一定次数。例如，1分钟、2分钟、4分钟等。“以指数级增长的间隔重试每个请求一组次数”不确定总是执行重试是不是一个好主意，在微服务的情况下，每个微服务都可以与其他微服务通信，并且不总是可以通过异步方式进行。在单用户请求期间，微服务之间可能会有大量HTTP调用（即使您试图将微服务隔离），在这种情况下，最终用户的响应时间可能会非常长。我同意应该由状态代码确定，微服务开发人员之间可以有一些内部合同/规则，使用什么状态，但仍然不总是清楚何时使用，使用什么状态，还有许多状态与应用程序本身无关，也不清楚在这种情况下执行什么。指数增长不需要几分钟。它可能是1秒、2秒、4秒等等，但如果您在自动伸缩环境中工作，则需要更长的时间来启动另一个服务器实例