指数退避和抖动故事

“指数退避，你等着瞧！！”
“什么？那是什么技术！？”

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

我本想时隔许久更新一下我的博客，但
我没有精力编写一些示例代码并做出一些可以运行的东西，所以
这次我将写一篇关于一个小算法的文章。

例如

当客户端与服务器通信期间服务器返回错误时，
客户端可能采取以下行为：

① 显示错误信息并取消进程
② 再次执行相同的通信（重试）
③ 进程无法继续

③ 只是一个 bug，所以肯定不行，但我认为大多数情况会是 ① 或 ②。
特别是对于处理过程不能中断的流程，我认为你会希望通过 ② 来恢复。

重试

我们来思考一下重试机制。

如果仅仅
因为响应出错就重试如果服务器端出现问题，
所有用户都会不断重试，这可能
：服务器负载急剧上升（这种情况与拒绝服务攻击无异），最终导致服务器宕机
。
我至今还对这种事记忆犹新……

用于分配如此高负载的算法
是开头提到的“指数退避算法”。

指数退避

从字面上讲，
指数
退避
是一种以指数方式递减（延迟）重试间隔的算法。

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

AWS 也对此有所解释。AWS
解释

抖动

然而，简单的指数函数可能会导致大量并发请求
（因为同时访问的用户会使用相同的重试间隔）
。这就是为什么指数函数需要配合“抖动”使用。
顾名思义
，抖动就等于时间延迟
。
通过使用随机值来设定重试间隔的范围，可以分散同时发生的重试。

AWS 解决方案架构师博客上的一篇文章
提供了验证结果的详细摘要

概括

实际上，你需要考虑诸如最大重试次数和超时之类的事情，但
这次我们只引入指数退避和抖动。

如果遇到暂时性错误或故障，重试通常可以解决问题。
如果恢复需要一些时间，
，通过执行此处介绍的高效重试
系统造成不必要压力的情况下改善情况。

顺便说一句，

我用开场白开了个小玩笑，想吸引观众的注意力，因为我听到有人说： “指数退避听起来像是一个特殊招式。”

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