Hystrix问题记录

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

内容简介:考虑这样一个场景,先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


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

查看所有标签

猜你喜欢:

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

Inside Larry's and Sergey's Brain

Inside Larry's and Sergey's Brain

Richard Brandt / Portfolio / 17 Sep 2009 / USD 24.95

You’ve used their products. You’ve heard about their skyrocketing wealth and “don’t be evil” business motto. But how much do you really know about Google’s founders, Larry Page and Sergey Brin? Inside......一起来看看 《Inside Larry's and Sergey's Brain》 这本书的介绍吧!

在线进制转换器
在线进制转换器

各进制数互转换器

图片转BASE64编码
图片转BASE64编码

在线图片转Base64编码工具

HEX CMYK 转换工具
HEX CMYK 转换工具

HEX CMYK 互转工具