Hystrix问题记录

栏目: 后端 · 发布时间: 6年前

内容简介:考虑这样一个场景,先new了一个Command(commandKey="commandA"),他的隔离策略是信号量隔离(ExecutionIsolationStrategy.SEMAPHORE),之后又new了一个Command(commandKey="commandA"),不过它的隔离策略是线程隔离(ExecutionIsolationStrategy.THREAD),那么问题来了,这个新的command究竟是哪个隔离策略呢?当nenw一个新的command的参数设置阶段(也就是AbstractComm

考虑这样一个场景,先new了一个Command(commandKey="commandA"),他的隔离策略是信号量隔离(ExecutionIsolationStrategy.SEMAPHORE),之后又new了一个Command(commandKey="commandA"),不过它的隔离策略是线程隔离(ExecutionIsolationStrategy.THREAD),那么问题来了,这个新的command究竟是哪个隔离策略呢?

还是信号量隔离,因为Hystrix有针对commandKey的缓存。

当nenw一个新的command的参数设置阶段(也就是AbstractCommand.initCommandProperties方法)时,会优先查看缓存里commandKey是否已经存在,如果存在直接返回。

[图片上传失败...(image-43d75f-1539487185510)]

2、信号量隔离(semaphore-isolated)的超时处理

Hystrix的官方wiki上说的是“This allows Hystrix to shed load without using thread pools but it does not allow for timing out and walking away.”。这句话让我产生了误解, 其实他的意思并不是说信号量隔离不支持超时,而是不支持超时之后立刻返回。

其实很好理解,因为信号量隔离并没有使用线程池,所以这个command执行的线程就是caller的线程,所以没有办法中断这个线程,甚至我们可以说,这样做是极度不安全的,因为可能会中断应用线程。

那么,如果使用了信号量隔离,并且配置了超时时间1s,那么如果超时了5s,会发生什么呢?

这个command还是会执行5s才回返回,不过返回的是getFallback返回的结果。

[图片上传失败...(image-8f6fa0-1539487185510)]

相关阅读: ExecutionIsolationStrategy.SEMAPHORE and interrupt-on-timeout

3、线程隔离下的getFallback在哪个线程里执行

Hystrix问题记录
Hystrix问题记录
Hystrix问题记录

这几张图其实不是我想说明这个问题而截得,不过正好也可以用来说明,这里总结下。

  • 如果是正常的执行,抛异常,那么getFallback是在我们定义的线程池中执行;
  • 如果是因为超时被中断,那么getFallback是在Timer的线程池(这是Hystrix自己的一个线程池,专门跑定时任务,用来计时)中执行;
  • 如果已经被熔断了,那么getFallback是在caller所在的线程中执行;
  • 如果是command超出了队列限制,那么getFallback是在caller所在的线程中执行;

4、Hystrix执行失败但不能进入fallback的问题

如果command执行方法抛出的throwable是:

  • StackOverflowError
  • VirtualMachineError
  • ThreadDeath
  • LinkageError

中的Error,那么Hystrix不会进入fallback方法,而会直接抛出HystrixRuntimeException,因为这几个Error被认为是 不可恢复错误

AbstractCommand.java :

Hystrix问题记录
Hystrix问题记录
Hystrix问题记录

5、HystrixRuntimeException: Command fallback execution rejected.

异常全文是:

com.netflix.hystrix.exception.HystrixRuntimeException: TestCommand fallback execution rejected.
复制代码

执行错误了,本应该去执行fallback方法,可是却被reject了,为什么呢?

这种情况下,一般来说是command已经熔断了,所有请求都进入fallback导致的,因为fallback默认是有个并发最大处理的限制, fallback.isolation.semaphore.maxConcurrentRequests ,默认是10,这个方法及时很简单,处理很快,可是QPS如果很高,还是很容易达到10这个阈值,导致后面的被拒绝。

解决方法也很简单:

  • fallback尽可能的简单,不要有耗时操作,如果用一个http接口来作为另一个http接口的降级处理,那你必须考虑这个http是不是也会失败;
  • 可以适当增大 fallback.isolation.semaphore.maxConcurrentRequests

如果关心具体处理逻辑的话,可以看下 AbstractCommand.getFallbackOrThrowException


以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

设计之下

设计之下

搜狐新闻客户端UED团队 / 电子工业出版社 / 2014-1-1 / CNY 69.00

形而上者谓之道,形而下者谓之器。匠者,器也。处身平凡的匠人不断追求向上的设计之道。本书没有华丽的辞藻和长篇大论的理论,作者是搜狐一线的设计团队,写作过程中他们尽力还原真实的工作场景,并总结出了一些实用的经验和方法。 《设计之下》共三部分,全面讲解了用户体验设计的流程和方法。第一部分为“交互设计”,阐述了从项目启动、解析需求到原型设计的过程,并且总结了交互设计的要点:大局观、操作流程简捷、形式......一起来看看 《设计之下》 这本书的介绍吧!

JSON 在线解析
JSON 在线解析

在线 JSON 格式化工具

SHA 加密
SHA 加密

SHA 加密工具

RGB HSV 转换
RGB HSV 转换

RGB HSV 互转工具