为什么指数退避算法能完美运行 | AI生成和翻译
这就是 exponential backoff，由于以下几个原因，它是一个非常优秀的架构设计：
它为临时性问题提供了解决的时间。 Network issues、server overloads 或 rate limits 通常是瞬时的。逐渐增加的延迟给了系统恢复的时间——一个在 1 秒后仍然存在的问题，可能在 4 秒或 16 秒后就消失了。
它能防止情况进一步恶化。 如果一个 server 正在高负载下挣扎，立即 retry 只会增加更多负载。exponential spacing 意味着你不会持续冲击一个已经压力巨大的系统，否则会减慢恢复速度或导致 cascading failures。
它对其他用户很公平。 当许多 client 同时遇到错误时（例如在短暂的 outage 期间），exponential backoff 会自然地错开它们的 retries，而不是造成 “thundering herd” 效应（即所有人都在同一时刻进行 retry）。
它平衡了响应速度与资源消耗。 初始的 retries 发生得很快（1、2 秒），以捕捉短暂的 hiccups；但不断增长的间隔可以防止你的 application 在可能徒劳的尝试上浪费资源，同时最终仍能检查系统是否已恢复。
它能很好地配合 rate limits。 许多 API 都会执行 rate limits（例如“每分钟 100 个 requests”）。exponential backoff 自然地拉开了 retries 的间距，因此在你被 throttled 之后，不太可能立即再次达到限制。
大多数 production 环境的实现还会加入 jitter（将延迟稍微随机化，例如使用 8±2 秒而不是精确的 8 秒），以防止多个 client 在经历相同 outage 时产生同步的 retries；同时还会设置一个 maximum delay 上限（例如 60 秒），这样你就不会在两次尝试之间等待数小时。