Hystrix selects a thread pool policy for resource isolation

This is the third day of my participation in Gwen Challenge

The previous article – [SpringCloud series] – Hystrix isolation policy selection mentioned Hystrix implementing resource isolation two strategies. The next article focuses on Hystrix implementing resource isolation using thread pool strategy

Resource isolation

All calls to a dependent service are isolated in the same resource pool and no other resources are used

Solve core business scenarios:

Isolates multiple dependent on service calls to pool their resources, to avoid dependence on a service call, because depend on the service interface call delay or failure, lead to service all threads all resources cost on the service interface call, once a service thread resources exhausted, all can lead to service collapse, and even the fault spreading.

For example, the member service initiates calls at the same time to 1000, but there are only 10 threads in the thread pool, so only 10 threads will be invoked at most to execute the call, but not the member service, because the interface invocation is delayed, and all thread resources in Tomcat will be exhausted.

How to set command key, Command group, and Command Thread pool values?

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;
}   

Copy the code

In the previous article, WE learned that Command Key represents an interface of a low-level dependent service, Command Group represents a low-level dependent service, and ThreadPoolKey represents a HystrixThreadPool for unified monitoring, statistics, and caching. The default ThreadPoolKey is the name of the Command group. Each command is bound to a ThreadPool corresponding to its ThreadPoolKey

Thread pool key parameters:

  • CoreSize Sets the size of the thread pool. The default is 10
HystrixThreadPoolProperties.Setter().withCoreSize(int value);
Copy the code
  • queueSizeRejectionThreshold

All 10 threads in the thread pool are working, and there is no idle thread to do the task. If there is any request coming from the thread pool, it will enter the queue backlog first. If the queue backlog is full, it will directly reject the request, execute fallback degradation logic, and quickly return.

The task delivery flow chart is as follows:

Reject threshold when the queue is full. Since maxQueueSize does not allow hot modification, provide this parameter to control the maximum size of the queue

HystrixThreadPoolProperties.Setter().withQueueSizeRejectionThreshold(int value);
Copy the code