原文链接:https://www.dubby.cn/detail.html?id=9100
考虑这样一个场景,先new了一个Command(commandKey="commandA"),他的隔离策略是信号量隔离(ExecutionIsolationStrategy.SEMAPHORE),之后又new了一个Command(commandKey="commandA"),不过它的隔离策略是线程隔离(ExecutionIsolationStrategy.THREAD),那么问题来了,这个新的command到底是哪个隔离策略呢?
还是信号量隔离,由于Hystrix有针对commandKey的缓存。
当nenw一个新的command的参数设置阶段(也就是AbstractCommand.initCommandProperties方法)时,会优先查看缓存里commandKey能否已经存在,假如存在直接返回。
[图片上传失败...(image-43d75f-1539487185510)]
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
这几张图其实不是我想说明这个问题而截得,不过正好也可以用来说明,这里总结下。
假如command执行方法抛出的throwable是:
中的Error,那么Hystrix不会进入fallback方法,而会直接抛出HystrixRuntimeException,由于这几个Error被认为是不可恢复错误。
AbstractCommand.java
:
异常全文是:
com.netflix.hystrix.exception.HystrixRuntimeException: TestCommand fallback execution rejected.
执行错误了,本应该去执行fallback方法,可是却被reject了,为什么呢?
这种情况下,一般来说是command已经熔断了,所有请求都进入fallback导致的,由于fallback默认是有个并发最大解决的限制,fallback.isolation.semaphore.maxConcurrentRequests,默认是10,这个方法及时很简单,解决很快,可是QPS假如很高,还是很容易达到10这个阈值,导致后面的被拒绝。
处理方法也很简单:
假如关心具体解决逻辑的话,可以看下
AbstractCommand.getFallbackOrThrowException