指数退避和抖动

“接招吧，指数退避！！”
“这是什么招式！？”

看来接下来要发生一件相当令人费解的事……不过，
感谢你的辛勤付出。
我是系统开发部的活死人松山。

我本想在很久之后更新一下我的博客，但
我没有精力编写任何示例代码并创建一些可运行的东西，所以
这次我将写一些关于算法的内容。

例如

当客户端与服务器通信时，如果服务器返回错误，
客户端可能采取哪些行为？

① 显示错误信息并取消进程。②
尝试再次执行相同的通信（重试）。③
无响应。

③ 纯粹是个 bug，因此肯定不行，但我认为大多数情况要么是①，要么是②。
特别是，对于处理过程不能中断的流程，你很可能希望通过②来恢复。

重试

我们来仔细想想重试机制。
因为响应出错就重试
如果仅仅
如果服务器因为任何原因发生故障，
所有用户都会继续重试（本质上就是拒绝服务攻击），这可能会导致
服务器崩溃
，甚至
我对此记忆犹新，因为这种情况真的发生过……

因此，用于分配如此高负载的算法
是前面提到的“指数退避”算法。

指数退避

直接翻译如下：
exponential = 指数函数
，backoff = 向后
。该算法以指数方式延迟（减小）重试间隔。

如果发生错误，重试
1 秒、2 秒、4 秒、8 秒等
，从而减少重试的总次数，实现高效重试。

AWS 也提供了相关解释。AWS
解释

抖动

然而，简单的指数函数会导致许多请求同时发生
（因为同时访问的用户会使用相同的重试间隔）
。这时就需要引入“抖动”（jitter），它与指数函数结合使用。
抖动字面
时间延迟
意思是
其理念是通过在重试间隔中引入一系列随机值来分散同时发生的重试。

AWS 解决方案架构师博客上的一篇文章
有关调查结果的详细分析，请参阅

概括

实际上，我们还需要考虑重试次数和超时次数的限制，但
目前我们只引入指数退避和抖动。

对于暂时性错误或故障，重试通常可以解决问题。
当恢复需要一些时间时，与其持续重试，不如使用
改善情况，又不会给系统带来不必要的负载
既能

顺便说一句，
“指数退避听起来像是一个特殊招式，不是吗？”
我用这句话作为开场白是因为我听到有人说：

很简单，但今天就先说到这里吧。