Polly断路器能否具有指数durationOfBreak？

Posted 2021-04-15

当我们因为耗尽连接池而收到超时异常时，我们正在尝试为数据库逻辑实现重试策略。当我们在一小段时间内出现异常大的活动时，会发生这种情况。我们已经增加了最大池大小以试图避免这种情况，但我们也希望将重试逻辑作为备份计划。

documentation for connection pooling说：

启用连接池时，如果发生超时错误或其他登录错误，将引发异常，并且后续连接尝试将在接下来的五秒（“阻塞期”）内失败。如果应用程序尝试在阻塞期内连接，则将再次抛出第一个异常。阻塞期结束后的后续故障将导致新的阻塞时段是前一个阻塞时段的两倍，最多为一分钟。

通过Fallback，WaitAndRetry和Circuit Breaker策略的PolicyWrap组合，Polly似乎非常适合解决这个问题。这张here有很好的照片

理想情况下，我希望能够为断路器指定一个指数durationOfBreak，以匹配上述的倍增周期。我没有在网上看到任何可能的例子，所以也许这是不可能的？

这里有什么理想的配置方法？是指定具有5秒durationOfBreak的断路器，然后对5,10,20,40和60秒的WaitAndRetry组件使用指数重试？在连接刚刚可用并且您的旧操作刚刚开始其等待40秒而新操作立即起作用的情况下，这似乎是不幸的。

另一种可能性是使用5秒durationOfBreak然后使WaitAndRetry组件使用非常小的等待并进行大量重试，即使我们知道如果它们在文档状态之前出现，其中许多重试将失败。

感谢您的反馈！

答案

Polly不提供具有变化（例如指数）断续持续时间的断路器。

下面可能看起来反直觉，但是：听起来好像这种情况不需要带有指数退避的断路器，因为所描述的ADO.NET连接池算法已经有效地提供了这种功能。

推理：断路器的目的是停止将呼叫通过一个不太可能应对它们的下游系统，以便：（a）快速向呼叫者失败; （b）保护基础系统免受过度负荷。听起来好像ADO.NET的算法已经实现了这两个目标。

类似地，指数退避重试策略的目标是防止重试自身“倍增”负载（在底层系统上创建自引发的DDOS攻击......更多请求进入并且现有请求也在重试）。同样，听起来ADO.NET的强制退避算法正在强制执行自己的指数退避以保护底层数据库，因此（*）可能（*）在分层您自己的Polly指数背后没有任何好处 - 最重要的是。

在ADO.NET提供自己的防御的基础上，我很想做一些简单的事情，例如使用固定重试间隔为5秒或5加微小垫片的重试策略。 （无论“阻塞期”是什么，似乎它将是5秒的倍数。）

这个建议是基于这样一个假设：这个ADO.NET连接池管理（就这个阻塞期而言）所有正在发生的呼叫方;即，嵌入在调用应用程序中的ADO.NET代码决定其连接池被充分利用，并在阻塞期间拒绝进一步的连接尝试，而不将网络调用通过底层SQL服务器进行检查。如果该假设不正确，那么上面的建议（*）可能是错误的，您最好使用指数退避重试策略来避免连接重试尝试重载数据库服务器。

---

警告：我没有直接使用这个特定的ADO.NET限制。那些可能有更好建议的人。那些更了解内部ADO.NET架构的人可能会更清楚地知道每隔五秒（正如我所建议的）继续尝试可能会被拒绝的“代价是多少”。

---

附录：此讨论还忽略了调用者内导致线程/ CPU饥饿或类似情况的高并行需求的任何维度。如果这是一个问题，请考虑pro-active load shedding在一些已知的可容忍限度。