问题标签 [circuit-breaker]

我对关闭的端点进行了调用，但是 hystrix 不执行回退方法，并引发异常：

有人知道是否缺少任何配置吗？

我的主要

和我的服务：

上下文：在 Tomcat 中运行的 Java Web 应用程序，Log4j 2 版本 2.5。日志记录设置为使用Raven 连接器和一个 ELK（ElasticSearch + Logstash + Kibana）实例转到一个Sentry实例。

配置如下所示（匿名）：

问题是，如果 Sentry 或 ELK 开始出现问题（响应时间长、无法访问……），应用程序线程在尝试记录时会被阻塞，应用程序实际上会死掉。

这个问题有首选的解决方案吗？某种断路器在这里是理想的：在检测到远程日志记录目标 Log4j 2 的问题后，将禁用附加程序一段时间。

我们使用另一个包装在 appender 中的<Async/>appender，但据我所知，这是一个很好的解决方案，可以使日志记录......好吧，异步，但不能解决无响应日志目标的问题。

没有 Future，这就是我如何将所有较小的 Seq 组合成一个带有平面图的大 Seq

现在该方法getCategoryUrlKey可能会失败。我在前面放了一个断路器，以避免在大量maxFailures之后为下一个元素调用它。现在断路器不返回 aSeq而是返回 aFuture[Seq]

如何遍历 ListappDomains并将结果组合成一个 Future[Seq] ，可能成为 Seq ？

如果函数式编程适用，有没有办法在没有临时变量的情况下直接转换？

我有一个IGetHamburgers调用外部 API 的查询。我已将IGetHamburgersDI 容器中的实现注册为单例。我使用 Polly 作为断路器，如果两个请求失败，电路将打开。

我的目标是所有对 Hamburger api 的调用都应该通过同一个断路器，如果 GetHamburgers 失败，那么所有其他调用也应该失败。

我应该如何使用我的保单？我应该将我的政策注册为这样的字段：

或者

我猜第一个选项是正确的方法，因为那时 Policy 对象将始终相同，并且可以跟踪异常计数和类似的东西。我的问题是，第二个选项也可以吗？我在 Pollys Github 上找到了很多示例/示例，但我找不到任何将 Polly 与 DI 以及类似的东西一起使用的“真实世界”示例？

我的断路器有问题。如果我向我的服务发送垃圾邮件请求，电路OPEN会正确并解决超时错误。在我设置的超时之后，电路进入HALF_OPEN状态 - 一切都应该如此。但从这里开始，电路再也不会关闭。每个请求都会导致错误并立即再次打开电路。

我使用 cb 通过 vertx eventBus 在我的服务之间进行通信，如下所示：

我的断路器选项：

我的配置错了吗？我是否可能错误地使用了 rxified API？

编辑 如果我在 docker 容器中运行我的代码，我只会收到错误消息： io.vertx.core.impl.NoStackTraceThrowable: operation timeout

如果我在本地启动应用程序，我会看到 PG/SQL 实际上抛出了一个sorry, too many clients异常。这当然可以解释为什么电路仍然打开，但是由于我已经关闭了成功和错误的客户端，所以我真的不明白为什么会发生这种情况。

--

似乎我当前在请求后关闭连接的方式是错误的。当我通过检查我的数据库连接时，SELECT * FROM pg_stat_activity where state = 'idle'我可以看到实际上没有任何请求正确终止。

我执行 db 查询的 java 代码如下所示：

我io.vertx:vertx-mysql-postgresql-client:3.4.1用作司机

Spring 的 @Retryable 注解将重试 3 次（默认）并回退到 @Recovery 方法。但是，@CircuitBreaker 将重试一次并在状态关闭时回退。

我想把这两个结合起来：当断路器状态关闭时，会在回退前重试3次（处理瞬态错误），如果状态打开，则直接回退。

有什么优雅的方法可以做到这一点？一种可能的方法是在函数内部实现重试逻辑，但我觉得这不是最好的解决方案。

我是 Polly 的新手，正在尝试创建一个具有回退和超时策略的断路器。我的设置如下所示，其中所有策略都是“全局”的，因此它们在调用之间保持状态：

后来我使用 _policy 来调用外部 webapi：

我想要实现的是如果断路器策略与超时策略相结合，则激活回退响应......使用当前设置，它在第一轮工作，即在该回退启动后 20 秒内发生 5 个错误......我等待 30 sek 和现在只有 1 次超过 1500 毫秒的后备再次启动（？），但这还为时过早，因为断路器策略应该在 20 秒跨度内进行 5 次尝试，然后回退开始......如果有人能指出我，我会很高兴在正确的方向如何解决这个问题。

谢谢！

default_circuitBreakerRequestVolumeThreshold=20 hystrix 中的默认配置是否意味着在 10 秒间隔内只允许 20 个请求和 1 秒存储桶？例如：如果在过去 10 秒内每秒有超过 2 个请求，hsytrix 会打开电路吗？

我正在构建一个 API，它将充当n 个底层 API 的代理，它们都做同样的事情。它将使用断路器模式来确定底层 API 之一何时不可用，因此代理 API 将具有状态。一种解决方案是在 AWS lambda 上运行 API 并将断路器状态存储在 AWS ElastiCache 中。

是否有另一种更具成本效益的解决方案，不需要我运行像 ElasticCache 这样的“始终在线”服务？

我正在尝试了解确保服务高可用性的断路器。我是新手。有人可以解释一下它实际上是什么以及我如何在系统中使用可用性。我看到很多同样的弧度，但我不清楚。我想基本上实现它以在系统中具有高可用性。