- 在某些情况下 ， 每次行动都会失败 ， 考虑如何处理这种情况是至关重要的 。
- 尽管重试策略将定义一个操作应该重试的最大次数 ， 但它不会阻止应用程序以相同的重试次数再次重复该操作 。 例如 ， 如果一个订单处理服务由于一个致命错误而失败 ， 使其永久停止操作 ， 重试策略可能会检测到连接超时 ， 并认为这是一个暂时的错误 。 代码将重试指定次数的操作 ， 然后放弃 。 然而当另一个客户下订单时 ， 该操作将再次尝试——即使每次都肯定会失败 。
- 为了防止对不断失败的操作进行不断重试 ， 考虑实现断路器模式 。 在此模式中 ， 如果指定时间窗口内的失败次数超过阈值 ， 则请求将立即作为错误返回给调用者 ， 而不尝试访问失败的资源或服务 。
- 应用程序可以周期性地测试服务（断断续续的 ， 请求之间的间隔很长） ， 以检测服务何时可用 。 适当的间隔取决于场景 ， 例如操作的关键程度和服务的性质 ， 可能是几分钟到几个小时之间的任何时间 。 在测试成功时 ， 应用程序可以恢复正常操作 ， 并将请求传递给新恢复的服务 。
- 与此同时 ， 可以退回到服务的另一个实例（可能在不同的数据中心或应用程序中） ， 使用提供兼容（可能更简单）功能的类似服务 ， 或者执行一些替代操作 ， 希望该服务很快可用 。 例如 ， 可以将服务请求存储在队列或数据存储中 ， 稍后再重放它们 。 否则我们可能会将用户重定向到应用程序的另一个实例 ， 降低应用程序的性能 ， 但仍然提供可接受的功能 ， 或者只是向用户返回一条消息 ， 指示该应用程序目前不可用 。
- 在决定重试次数和策略重试间隔的值时 ， 请考虑服务或资源上的操作是否是长时间运行或多步骤操作的一部分 。 当一个操作步骤失败时 ， 补偿所有其他已经成功的操作步骤可能是困难的或昂贵的 。 在这种情况下 ， 很长的间隔和大量的重试是可以接受的 ， 只要它不通过持有或锁定稀缺资源来阻塞其他操作 。
- 请考虑重试同一操作是否可能导致数据不一致 。 如果重复多步骤流程的某些部分 ， 且操作不是幂等的 ， 则可能导致不一致 。 例如 ， 递增值的操作如果重复 ， 将产生无效的结果 。 如果无法检测到重复的消息 ， 重复将消息发送到队列的操作可能会导致消息使用者中出现不一致 。 要防止这种情况 ， 请确保将每个步骤设计为幂等操作 。
- 考虑将要重试的操作的范围 。 例如 ， 在包含多个操作的级别上实现重试代码可能更容易 ， 如果其中一个操作失败 ， 则重试所有操作 。 但是 ， 这样做可能会导致幂等问题或不必要的回滚操作 。
- 如果选择一个包含多个操作的重试范围 ， 那么在确定重试间隔、监视所花费的时间以及发出失败警报之前 ， 请考虑所有操作的总延迟 。
特别声明：本站内容均来自网友提供或互联网，仅供参考，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系，我们将在24小时内删除。