指数退避和抖动故事

“可恶，指数退避！！
”

一个我不明白的故事即将展开……
谢谢你们的辛苦。
这是系统开发部的松山，也被称为活死人。

距离上次更新博客已经有一段时间了，但是
我没有动力去写一些示例代码并让一些东西发挥作用，所以
我想这次我应该写一些关于算法的内容。

例如

客户端 ↔︎ 如果服务器之间通信期间从服务器返回错误，
客户端可能的行为是：

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

③是不可能的，因为它只是一个错误，但我认为主要是①或②。
特别是在处理不能中断的流程的情况下，我认为您会期望从②中恢复。

重试

让我们考虑一下重试。
响应只是一个错误，所以我会再试一次。
这种情况下，请求→响应（错误）→重试的过程就会无限重复。
如果服务器端由于某种原因发生故障，
所有用户都会不断重试（情况与DoS攻击没有什么区别），
服务器的负载会突然增加，最终服务器会宕机，
这可能会导致。最糟糕的情况。
它实际上是一个痛苦的回忆......

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

指数退避

直接翻译一下，
·Exponential = Exponential
·Backoff = Backward
，意思是它是一种将重试间隔以指数方式向后移动（延迟）的算法。

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

AWS上也有解释。
AWS解释

抖动

然而，简单的指数函数可能会导致许多请求同时发生。
（同时访问的用户将具有相同的重试间隔。）
因此，“抖动”与指数结合使用。
直接翻译一下
，抖动=时滞
。
通过使用随机值赋予重试间隔宽度，可以分布同时重试。

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

概括

现实中，需要考虑重试次数上限、超时等问题，但
这次我们只介绍指数退避和抖动。

在出现临时错误或失败的情况下，我认为重试通常可以解决问题。

请记住，如果需要一些时间才能恢复，
您可以通过像这里介绍的那样进行有效的重试来改善情况，而不会给它带来不必要的负担

，我一开始用这个
“指数退避就像一个特殊的动作，不是吗？”

很简单，但这就是今天的故事的全部内容。