（b）增量间隔：应用程序在第一次重试之前短暂等待 ， 每个后续重试的间隔时间增量递增 。 例如 ， 在3秒、7秒、13秒后重试操作 。
（c）固定间隔：应用程序每次尝试的间隔时间相同 。 例如 ， 固定每3秒重试操作 。
（d）立即重试：有时临时性故障很短暂 ， 可能是由于网络数据包冲突或硬件组件出现峰值等事件 。 在此情况下 ， 适合立即重试操作 ， 因为如果故障在操作让应用程序组合并发送下一个请求时已清除 ， 则操作可能会成功 。 但是不应有多次立即重试尝试 ， 如果立即重试失败 ， 应切换到备用策略 ， 例如指数退让或回退操作 。
（e）随机化：上面列出的任何重试策略都可能包括随机化 ， 以防止客户机的多个实例同时发送随后的重试尝试 。 例如 ， 一个实例可能在3秒、11秒、28秒之后重试该操作 ， 而另一个实例可能在4秒、12秒、26秒之后重试该操作 。 随机化是一种有用的技术 ， 可以与其他策略相结合 。
- 一般指导原则是 ， 为后台操作使用指数退让策略 ， 为交互式操作使用立即或固定间隔重试策略 。 在上述两种情况下 ， 应该选择延迟与重试计数 ， 使所有重试的延迟上限都在所需的端到端延迟要求范围内 。
- 考虑影响重试操作的总的最大超时的所有因素的组合 。 这些因素包括失败连接产生响应所花费的时间（通常由客户端中的超时值设置）以及重试尝试和最大重试次数之间的延迟 。 所有这些时间的总和可能会导致较长的总体操作时间 ， 特别是当使用指数延迟策略时 ， 其中重试间隔在每次失败后迅速增长 。 如果流程必须满足特定的服务水平协议SLA ， 则整个操作时间（包括所有超时和延迟）必须在SLA定义的限制内 。
- 过于激进的重试策略（间隔太短或重试太频繁）可能会对目标资源或服务产生不利影响 。 这可能会阻止资源或服务从其重载状态中恢复 ， 并且它将继续阻塞或拒绝请求 。 这导致了一个恶性循环 ， 越来越多的请求被发送到资源或服务 ， 从而进一步降低了其恢复能力 。
- 在选择重试间隔时 ， 要考虑操作的超时时间 ， 以避免立即启动后续的尝试（例如 ， 如果超时时间与重试间隔类似） 。 还要考虑是否需要将可能的总时间（超时加上重试间隔）保持在特定的总时间以下 。 超时时间异常短或异常长的操作可能会影响等待多长时间以及重试操作的频率 。
- 使用异常的类型和它包含的任何数据 ， 或者从服务返回的错误代码和消息 ， 来优化重试的间隔和次数 。 例如 ， 一些异常或错误代码（例如响应中带有Retry-After头的HTTP代码503 Service Unavailable）可能指示错误可能持续多长时间 ， 或者服务已经失败 ， 不会响应任何后续的尝试 。
- 在绝大多数情况下 ， 应该避免包含重复重试代码层的实现 。 避免包含级联重试机制的设计 ， 或者在涉及请求层次结构的操作的每个阶段实现重试的设计 ， 除非有要求这样做的特定需求 。 在这些异常情况下 ， 请使用防止过多重试次数和延迟时间的策略 ， 并确保理解其后果 。 例如 ， 如果某个组件对另一个组件发出请求 ， 后者再访问目标服务 ， 并且要对这两个调用各实施重试三次 ， 则总共会对该服务重试九次 。 许多服务和资源实施内置重试机制 ， 如果需要在较高级别实施重试 ， 应调查如何禁用或修改此设置 。
- 永远不要实现无止境的重试机制 。 这可能会阻止资源或服务从过载情况中恢复 ， 并导致节流和拒绝连接持续较长时间 。 使用有限的次数或重试 ， 或实现一个模式（如断路器） ， 以允许服务恢复 。
特别声明：本站内容均来自网友提供或互联网，仅供参考，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系，我们将在24小时内删除。