前言：

hystrix中，其实最核心的一个功能就是资源隔离，就是将多个依赖服务的调用分别隔离到各个资源的内部，避免因为依赖服务的失败或者延迟，导致服务所有的线程资源花费在这个伤害，继而导致服务崩塌。

线程池隔离和信号量隔离

hystrix中主要有两种资源隔离的技术：线程池隔离和信号量隔离。使用场景：线程池隔离技术：大部分的场景下其实都适合用这种技术，对于依赖服务的调用以及访问；能解决场景的timeout的场景，可以避免调用线程阻塞住。信号量隔离技术：通常是针对超大并发量的场景，每个服务实例的QPS都非常高，如果用线程池，可能撑不住那么高的并发，如果要撑住，可能要耗费大量的线程资源，那么就是用信号量，来进行限流保护。也就是说适合你的访问不依赖于外部服务，而只是访问内部的一些复杂的业务逻辑，由于他是内部访问，不存在timeout的问题，适合比较复杂逻辑的业务代码，防止大量的线程被这些逻辑给卡死，影响系统的稳定性。

区别：

线程池隔离技术，不是去控制web容器的线程，而是使用了线程池隔离技术，控制的是web容器中线程的执行，而非web容器本身的线程。

和信号量隔离有什么区别呢？比如说是一个容量为20的线程池和信号量个数，线程池其实是用自己的线程去调用web容器，而信号量隔离是直接让web容器的线程直接去调用依赖服务；前者会抛出异常，web容器的执行线程中可以捕获到，然后做进一步的处理。 而后者是直接返回。

资源隔离的相关概念

对于每一个command来说，其实都可以设置自己的名称，并且设置自己的分组command group。

command group：非常重要的概念，默认情况下，就是通过command group来定义一个线程池的，而且还会通过command group来聚合一些监控和报警信息；同一个command group中的请求，都会进入同一个线程池中。

command线程池

threadpool key代表了一个HystrixThreadPool，用来进行统一监控，统计，缓存；默认的threadpool key就是command group名称；每个command都会跟它的threadpool key对应的threadpool绑定在一起，如果不想直接用command group，也可手动设置threadpool name。

command threadpool VS command group VS command key

command key：代表了一类command，一般来说，抽象成底层的依赖服务的其中一个接口.

command group：代表了某一个底层的依赖服务，一个依赖服务可能会暴露出来多个接口，每个接口就是一个command key；在逻辑上去组织起来一堆command key的调用，统计信息，成功次数，timeout超时次数，失败次数，可以看到某一个服务整体的一些访问情况

command threadpool ：一般来说，推荐是根据一个服务去划分出一个线程池，command key默认都是属于同一个线程池的.

一般来说，command group是对应一个服务，多个command key对应该服务的多个接口，多个接口的调用共享同一个线程池;如下图：

当然如果说commandkey 需要用自己的线程池，也是可以自行定义。

coreSize

设置线程池的大小，默认是10

queueSizeRejectionThreshold

控制queue满后reject的容量，maxQueueSize不允许热修改，因此提供这个参数可以热修改，控制队列的最大大小；HystrixCommand在提交到线程池之前，其实会先进入一个队列中，这个队列满了之后，才会reject。这个机制其实跟之前的说的线程池的工作原理非常的相近。execution.isolation.semaphore.maxConcurrentRequests：设置使用SEMAPHORE隔离策略的时候，允许访问的最大并发量，超过这个最大并发量，请求直接被reject