1、CommandKey缓存问题

考虑这样一个场景，先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)]

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

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

如果是正常的执行，抛异常，那么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:

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