Hystrix选择线程池策略实现资源隔离
这是我参与更文挑战的第3天,活动详情查看: 更文挑战
上一篇文章-【SpringCloud系列】- Hystrix隔离策略选择
提到Hystrix实现资源隔离两种策略,接下来主要关注Hystrix采用线程池策略实现资源隔离
资源隔离
把某一个依赖服务的所有调用请求,全部隔离在同一份资源池内,不会去用其它资源
解决核心业务场景:
将多个依赖服务的调用分别隔离到各自的资源池内,避免对某一个依赖服务的调用,因为依赖服务的接口调用的延迟或者失败,导致服务所有的线程资源全部耗费在这个服务的接口调用上,一旦某个服务的线程资源全部耗尽,就可能导致服务崩溃,甚至这种故障不断蔓延。
例如:会员服务同时发起调用量到1000,但是线程池内就10个线程,最多就只会调用10个线程去执行,而不会对会员服务,因为接口调用延时,将tomcat内部所有的线程资源全部耗尽。
如何设定command key、command group、command thread pool的相关值?
1 | java复制代码private static final Setter cachedSetter = Setter.withGroupKey(HystrixCommandGroupKey.Factory.asKey("ExampleGroup")) |
上一篇文章了解到command key代表了底层的依赖服务的一个接口,command group代表了代表了某一个底层的依赖服务,而ThreadPoolKey代表了一个HystrixThreadPool,用来进行统一监控、统计、缓存。默认的ThreadPoolKey就是command group的名称。每个command 都会跟它的ThreadPoolKey对应的ThreadPool绑定在一起
线程池关键参数:
- coreSize设置线程池的大小,默认是10
1 | java复制代码HystrixThreadPoolProperties.Setter().withCoreSize(int value); |
- queueSizeRejectionThreshold
线程池中的10个线程都在工作中,没空闲的线程来做任务,此时再有请求过来,会先进入队列积压,如果说队列积压满了,再有请求过来,就直接reject,拒绝请求,执行fallback降级的逻辑,快速返回。
任务投递流程图如下:
控制queue满了之后reject的threshold,因为maxQueueSize不允许热修改,提供这个参数可热修改,控制队列的最大大小
1 | java复制代码HystrixThreadPoolProperties.Setter().withQueueSizeRejectionThreshold(int value); |
本文转载自: 掘金