- 应用程序必须能够检测到故障的发生 ， 并确定这些故障可能是临时性的、持久性的还是终端故障 。 发生故障时 ， 不同资源可能返回不同响应 ， 这些响应可能会根据不同操作而有所不同 。 例如 ， 针对从存储读取时所发生错误返回的响应 ， 与针对写入存储时所发生错误返回的响应不同 。 许多资源和服务都妥善制定了临时性故障的策略 。 但是若不提供此类信息 ， 则很难发现故障的性质 ， 以及故障是否是临时性的 。
- 如果确定故障可能是临时性的 ， 应用程序必须能够重试操作 ， 并跟踪操作重试的次数 。
- 应用程序必须使用适当的重试策略 。 此策略指定应用程序应该重试的次数、每两次尝试的延迟时间 ， 以及尝试失败后执行的操作 。 适当的尝试次数以及每两次尝试的延迟时间通常难以确定 ， 会根据资源类型以及应用程序本身的当前操作条件而有所不同 。
以下指南将帮助您为应用程序设计合适的临时性故障处理机制：
确定是否存在内置重试机制
- 许多服务提供SDK或包含临时性故障处理机制的客户端库 。 服务使用的重试策略通常是根据目标服务的性质和要求定制的 。 或者对于确定重试是否正确 ， 以及在下一次尝试重试之前要等待多长时间方面 ， 服务的REST接口可能会返回有用的信息 。
- 如果可用 ， 请使用内置重试机制 ， 除非有使不同重试行为更合适的具体且明确的要求 。
- 应该仅在暂时性故障 ， 以及在重新尝试时至少有一定成功的可能性之下才进行重试操作 。 对于指示无效操作（如对不存在的项进行数据库更新 ， 或对发生致命错误的服务或资源的请求）的操作 ， 重新尝试是没有意义的 。
- 一般而言 ， 只有在能够确定操作的全部影响并充分了解状况并可进行验证时 ， 才建议实施重试 。 否则应该由调用代码来实施重试 。 请记住 ， 从无法控制的资源与服务返回的错误可能会随着时间而演进 ， 可能需要重新建立访问临时性故障的检测逻辑 。
- 创建服务或组件时 ， 请考虑实现错误检查代码和消息处理 ， 以帮助客户端确定是否应该重试失败的操作 。 特别是 ， 指示客户端是否应该重试该操作 ， 并在下一次重试尝试之前建议一个适当的延迟 。 如果构建Web服务 ， 请考虑返回在服务契约中定义的自定义错误 。 即使通用客户端可能无法读取这些信息 ， 但在构建自定义客户端时它们将非常有用 。
- 优化用例类型的重试计数和间隔是至关重要的 。 如果没有重试足够次数 ， 应用程序将无法完成操作 ， 并可能经历失败；如果重试过多次 ， 或者重试间隔过短 ， 应用程序可能会长期占用线程、连接和内存等资源 ， 这将对应用程序的运行状况产生不利影响 。
- 时间间隔和重试次数的适当值取决于正在尝试的操作类型 。 例如 ， 如果操作是用户交互的一部分 ， 那么间隔应该很短 ， 并且只尝试几次 ， 以避免让用户等待响应(这会保持打开的连接并降低其他用户的可用性；如果操作是长时间运行或关键工作流的一部分 ， 其中取消和重新启动流程是费时费力的 ， 那么在尝试和重试之间等待更长时间是合适的 。
- 确定重试之间的适当间隔是设计成功策略中最困难的部分 。 典型策略使用以下类型的重试间隔：
（a）指数延迟：应用程序在第一次重试之前短暂等待 ， 每个后续重试的间隔时间呈指数增加 。 例如 ， 在3秒、12秒、30秒后重试操作 。特别声明：本站内容均来自网友提供或互联网，仅供参考，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系，我们将在24小时内删除。