本系列内容转载自git项目advancejava
Hystrix isolation of resources, there are two strategies:
• thread pool isolation
• semaphore isolation
Resource isolation of this one thing, in fact, can do some fine-grained control.
execution.isolation.strategy
Specifies the HystrixCommand.run()resource isolation strategy: THREAD or SEMAPHORE, based on the thread pool, based on the semaphore.
// to use thread isolation
HystrixCommandProperties.Setter().withExecutionIsolationStrategy(ExecutionIsolationStrategy.THREAD)
// to use semaphore isolation
HystrixCommandProperties.Setter().withExecutionIsolationStrategy(ExecutionIsolationStrategy.SEMAPHORE)
Thread pooling mechanism, each command runs in a thread, by limiting the size of the thread pool is controlled; semaphore mechanism, command in the calling thread is running, the signal is performed by limiting the amount of capacity.
How to choose between the thread pool and semaphores?
The default strategy is to thread pool.
In fact, the thread pool is the biggest advantage for network access request, if there is a timeout, then avoid calling thread to block live.
The scene using a semaphore, usually aimed at the large amount of concurrent scenes, each service instance are hundreds of QPS per second, then the time you use the thread pool, then the thread is generally not too much, so could barely high concurrency, if you want to shore, you may want to spend a lot of thread resources, it is to use a semaphore to be limiting protection. Usually the amount of signal that is common in some of the memory-based service business logic, not involving any network access request.
command key & command group
We use the thread pool isolation, how to rely on services, depend on the service interface, the thread pool is divided three do it?
Each command, can set its own name command key, and can set its own group command group.
private static final Setter cachedSetter = Setter.withGroupKey(HystrixCommandGroupKey.Factory.asKey("ExampleGroup"))
.andCommandKey(HystrixCommandKey.Factory.asKey("HelloWorld"));
public CommandHelloWorld(String name) {
super(cachedSetter);
this.name = name;
}
command groupIs a very important concept, by default, it is through command groupto define a thread pool, but also by command groupaggregating a number of surveillance and alarm information. The same command groupin the request, will enter the same thread pool.
command thread pool
ThreadPoolKeyIt represents a HystrixThreadPoolfor unified monitoring, statistics, cache. The default ThreadPoolKeyis the command groupname. Each commandwill saying the ThreadPoolKeycorresponding ThreadPoolbound.
If you do not want to directly command group, or you can manually set the ThreadPoolname.
private static final Setter cachedSetter = Setter.withGroupKey(HystrixCommandGroupKey.Factory.asKey("ExampleGroup"))
.andCommandKey(HystrixCommandKey.Factory.asKey("HelloWorld"))
.andThreadPoolKey(HystrixThreadPoolKey.Factory.asKey("HelloWorldPool"));
public CommandHelloWorld(String name) {
super(cachedSetter);
this.name = name;
}
command key & command group & command thread pool
command key, Represent a class command, in general, it represents an interface underlying dependent services.
command groupAnd represents one of the underlying dependency service, which is very reasonable, a service may be exposed depend on multiple interfaces, each interface is a command key. command groupIn the logic up to organize a bunch command keyof calls, statistics, the number of successes, timeouttimeouts, failures, etc., you can see some of the visits a particular service as a whole. In general, it is recommended to separate a thread pool according to a service area, command keyby default all belong to the same thread pool.
For example, you order a service granularity, estimated this all add up to the overall QPS interfaces per second at about 100 service, you call this service, this service is currently deployed in 10 service instances, each instance of the service, in fact, with this command groupcorresponds to the service, to a thread pool, probably in the amount of about 10 on it, your overall QPS access to the entire service would probably at about 100 per second.
But if the command group corresponds to a service, and several interfaces, visits the service exposed very different, the difference is very large. You may want the internal service command group, contained in the command key corresponding to multiple interfaces, do some of the fine-grained resource isolation. That is, different interfaces for the same service, using a different thread pool.
command key -> command group
command key -> 自己的 thread pool key
Logically, multiple command key part of a command group, doing statistics when statistics will be put together. Each command key has its own thread pool, each interface has its own thread pool, to do resource isolation and current limiting.
Said the white point, that if you use the command key own thread pool, you can define your own thread pool key, ok.
coreSize
Set the thread pool size, default is 10. In general, use this default size of 10 threads is enough.
HystrixThreadPoolProperties.Setter().withCoreSize(int value);
queueSizeRejectionThreshold
If the 10 threads in the pool are at work, there is no idle thread to do other things, then there is a request to come at this time, it will first enter the queue backlog. If the backlog queue is full, then the request has come, directly reject, deny the request, perform fallback degraded logical, quick return.
After the queue is full control of reject threshold, because maxQueueSizeheat can not be modified, so the heat can be modified to provide this parameter to control the maximum size of the queue.
HystrixThreadPoolProperties.Setter().withQueueSizeRejectionThreshold(int value);
execution.isolation.semaphore.maxConcurrentRequests
Set when using SEMAPHORE isolation policies to allow access to the maximum amount of concurrency, to exceed the maximum amount of concurrent requests directly reject.
The concurrency setting, with the thread pool size settings should be similar, but based on the semaphore, then the performance will be much better, but the cost Hystrix framework itself will be much smaller.
The default value is 10, set small as possible, because too much once set, but there is a delay occurs, it may lead to instant tomcat itself thread resources are occupied.
HystrixCommandProperties.Setter().withExecutionIsolationSemaphoreMaxConcurrentRequests(int value);