Hystrix选择线程池策略实现资源隔离

这是我参与更文挑战的第3天，活动详情查看： 更文挑战

上一篇文章-【SpringCloud系列】- Hystrix隔离策略选择 提到Hystrix实现资源隔离两种策略，接下来主要关注Hystrix采用线程池策略实现资源隔离

资源隔离

把某一个依赖服务的所有调用请求，全部隔离在同一份资源池内，不会去用其它资源

解决核心业务场景：

将多个依赖服务的调用分别隔离到各自的资源池内，避免对某一个依赖服务的调用，因为依赖服务的接口调用的延迟或者失败，导致服务所有的线程资源全部耗费在这个服务的接口调用上，一旦某个服务的线程资源全部耗尽，就可能导致服务崩溃，甚至这种故障不断蔓延。

例如：会员服务同时发起调用量到1000，但是线程池内就10个线程，最多就只会调用10个线程去执行，而不会对会员服务，因为接口调用延时，将tomcat内部所有的线程资源全部耗尽。

如何设定command key、command group、command thread pool的相关值？

private static final Setter cachedSetter = Setter.withGroupKey(HystrixCommandGroupKey.Factory.asKey("ExampleGroup"))
    	.andCommandKey(HystrixCommandKey.Factory.asKey("Gxin"))
     	.andThreadPoolKey(HystrixThreadPoolKey.Factory.asKey("GxinPool"));
public GxinCommand(String name){
    super(cachedSetter);
    this.name=name;
}   

上一篇文章了解到command key代表了底层的依赖服务的一个接口，command group代表了代表了某一个底层的依赖服务，而ThreadPoolKey代表了一个HystrixThreadPool,用来进行统一监控、统计、缓存。默认的ThreadPoolKey就是command group的名称。每个command 都会跟它的ThreadPoolKey对应的ThreadPool绑定在一起

线程池关键参数：

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

HystrixThreadPoolProperties.Setter().withCoreSize(int value);

• queueSizeRejectionThreshold 线程池中的10个线程都在工作中，没空闲的线程来做任务，此时再有请求过来，会先进入队列积压，如果说队列积压满了，再有请求过来，就直接reject,拒绝请求，执行fallback降级的逻辑，快速返回。

任务投递流程图如下：

控制queue满了之后reject的threshold,因为maxQueueSize不允许热修改，提供这个参数可热修改，控制队列的最大大小

HystrixThreadPoolProperties.Setter().withQueueSizeRejectionThreshold(int value);