Polly Circuit Breaker 可以有指数 durationOfBreak 吗？
Can a Polly Circuit Breaker have an exponential durationOfBreak?
当我们收到由于耗尽连接池而导致的超时异常时，我们正在尝试为我们的数据库逻辑实施重试策略。当我们在短时间内出现异常大的 activity 峰值时，就会发生这种情况。我们已经增加了最大池大小以尽量避免这种情况，但我们也希望将重试逻辑作为备份计划。
documentation for connection pooling 指出：
When connection pooling is enabled, and if a timeout error or other login error occurs, an exception will be thrown and subsequent connection attempts will fail for the next five seconds, the "blocking period". If the application attempts to connect within the blocking period, the first exception will be thrown again. Subsequent failures after a blocking period ends will result in a new blocking periods that is twice as long as the previous blocking period, up to a maximum of one minute.
Polly 似乎很适合解决这个问题，通过回退、WaitAndRetry 和断路器策略的 PolicyWrap 组合。这张图不错here
理想情况下，我希望能够为断路器指定指数 durationOfBreak 以匹配上述加倍周期。我还没有在网上看到任何关于这怎么可能的例子，所以也许这是不可能的？
此处所需的配置方法是什么？是指定一个5秒durationOfBreak的Circuit Breaker，然后对5秒、10秒、20秒、40秒、60秒的WaitAndRetry组件使用指数重试？在连接刚刚可用并且您的旧操作刚刚开始等待 40 秒而新操作将立即运行的情况下，这似乎很不幸。
另一种可能性是有 5 秒的 durationOfBreak，然后让 WaitAndRetry 组件使用非常短的等待时间并进行多次重试，尽管我们知道如果这些重试中的许多重试在文档说明之前发生，它们将会失败。
感谢您的反馈！
Polly 不提供具有不同（例如指数）断路持续时间的断路器。
以下内容乍一看似乎违反直觉，但是： 听起来好像这种情况不需要具有指数回退的断路器，因为 ADO.NET 描述的连接池算法已经有效地提供了这一点。
推理：断路器的目的是停止将调用传递给不太可能处理它们的下游系统，以便：(a) 失败快给来电者； (b) 保护底层系统免受过度负载。听起来好像 ADO.NET 的算法已经实现了这两个目标。
类似地，指数退避重试策略的目标是防止重试本身 "multiplying up" 负载（在底层系统上创建自我诱导的 DDOS 攻击......更多请求进入和现有请求也在重试）。同样，听起来 ADO.NET 的 force-you-to-back-off 算法正在强制执行其自身的指数后退以保护底层数据库，因此可能 (*) 对您自己的分层没有任何好处Polly 指数退避在此之上。
在 ADO.NET 提供自己的防御的基础上，我很想做一些简单的事情，比如使用固定重试间隔为 5 秒或 5-plus-tiny-shim 秒的重试策略。 （无论 "blocking period" 是什么，它似乎都是 5 秒的倍数。）
这个建议是基于这样的假设 ADO.NET 连接池管理（关于这个阻塞期）全部发生在调用方；也就是说，调用应用程序中嵌入的 ADO.NET 代码正在决定其连接池已被充分利用，并在阻塞期间拒绝进一步的连接尝试 而不会将网络调用传递到底层 SQL服务器检查。如果该假设不正确，那么上面的建议 (*) 可能是错误的，您 会 最好使用指数退避重试策略来避免连接重试尝试使数据库服务器过载.
警告：我没有直接使用这个特定的 ADO.NET 限制。那些有可能有更好的建议。那些更了解内部 ADO.NET 架构的人可能更了解 'expensive' 每五秒尝试一次（正如我所建议的那样）可能会被拒绝。
附录： 此讨论还忽略了调用者内部导致 thread/CPU 饥饿或类似情况的高并行需求的任何维度。如果这是一个问题，请考虑 pro-active load shedding 在某个已知的可容忍极限。
当我们收到由于耗尽连接池而导致的超时异常时，我们正在尝试为我们的数据库逻辑实施重试策略。当我们在短时间内出现异常大的 activity 峰值时，就会发生这种情况。我们已经增加了最大池大小以尽量避免这种情况，但我们也希望将重试逻辑作为备份计划。
documentation for connection pooling 指出：
When connection pooling is enabled, and if a timeout error or other login error occurs, an exception will be thrown and subsequent connection attempts will fail for the next five seconds, the "blocking period". If the application attempts to connect within the blocking period, the first exception will be thrown again. Subsequent failures after a blocking period ends will result in a new blocking periods that is twice as long as the previous blocking period, up to a maximum of one minute.
Polly 似乎很适合解决这个问题，通过回退、WaitAndRetry 和断路器策略的 PolicyWrap 组合。这张图不错here
理想情况下，我希望能够为断路器指定指数 durationOfBreak 以匹配上述加倍周期。我还没有在网上看到任何关于这怎么可能的例子，所以也许这是不可能的？
此处所需的配置方法是什么？是指定一个5秒durationOfBreak的Circuit Breaker，然后对5秒、10秒、20秒、40秒、60秒的WaitAndRetry组件使用指数重试？在连接刚刚可用并且您的旧操作刚刚开始等待 40 秒而新操作将立即运行的情况下，这似乎很不幸。
另一种可能性是有 5 秒的 durationOfBreak，然后让 WaitAndRetry 组件使用非常短的等待时间并进行多次重试，尽管我们知道如果这些重试中的许多重试在文档说明之前发生，它们将会失败。
感谢您的反馈！
Polly 不提供具有不同（例如指数）断路持续时间的断路器。
以下内容乍一看似乎违反直觉，但是： 听起来好像这种情况不需要具有指数回退的断路器，因为 ADO.NET 描述的连接池算法已经有效地提供了这一点。
推理：断路器的目的是停止将调用传递给不太可能处理它们的下游系统，以便：(a) 失败快给来电者； (b) 保护底层系统免受过度负载。听起来好像 ADO.NET 的算法已经实现了这两个目标。
类似地，指数退避重试策略的目标是防止重试本身 "multiplying up" 负载（在底层系统上创建自我诱导的 DDOS 攻击......更多请求进入和现有请求也在重试）。同样，听起来 ADO.NET 的 force-you-to-back-off 算法正在强制执行其自身的指数后退以保护底层数据库，因此可能 (*) 对您自己的分层没有任何好处Polly 指数退避在此之上。
在 ADO.NET 提供自己的防御的基础上，我很想做一些简单的事情，比如使用固定重试间隔为 5 秒或 5-plus-tiny-shim 秒的重试策略。 （无论 "blocking period" 是什么，它似乎都是 5 秒的倍数。）
这个建议是基于这样的假设 ADO.NET 连接池管理（关于这个阻塞期）全部发生在调用方；也就是说，调用应用程序中嵌入的 ADO.NET 代码正在决定其连接池已被充分利用，并在阻塞期间拒绝进一步的连接尝试 而不会将网络调用传递到底层 SQL服务器检查。如果该假设不正确，那么上面的建议 (*) 可能是错误的，您 会 最好使用指数退避重试策略来避免连接重试尝试使数据库服务器过载.
警告：我没有直接使用这个特定的 ADO.NET 限制。那些有可能有更好的建议。那些更了解内部 ADO.NET 架构的人可能更了解 'expensive' 每五秒尝试一次（正如我所建议的那样）可能会被拒绝。
附录： 此讨论还忽略了调用者内部导致 thread/CPU 饥饿或类似情况的高并行需求的任何维度。如果这是一个问题，请考虑 pro-active load shedding 在某个已知的可容忍极限。