Hystrix configuration Parameters Fully resolved

Objective

Not long ago in the Department of the week to share the Hystrix source parsing, the helpless back on the expert baggage , colleagues think I am very familiar with hystrix, we contact hystrix more or work in the use and configuration, so many people encounter hystrix The configuration problem will come over to ask me. In order not to let them down, I took the Hystrix configuration document carefully read over, will have the point of doubt through the source, check the official issue, the way of their own experiments to sort out, this only to hystrix configuration has a certain understanding.

In the process of understanding these configuration items, I also found a lot of pits, and the usual values that we think of as a matter of course do not allow hystrix to work as expected, and the configuration that has not been carefully copied and pasted will make Hystrix never work. So write down this article, hope can help small partners master Hystrix. If you want to know Hystrix, you can match my previous share Ppt:hystrix source parsing

Article Welcome, please respect the author's labor results, with the original link: www.cnblogs.com/zhenbianshu/p/9630167.html

Hystrixcommand How to configure

Our configuration is based on Hystrixcommand, we implement the configuration by adding annotations on the method @HystrixCommand and configuring the parameters of the annotations, but sometimes there are multiple hystrix methods in a class, and each method is similar to the configuration, it will be redundant with many code. At this point we can use annotations on the class to @DefaultProperties set a default value for the Hystrix method of the entire class.

Configuration Items

The following are the parameters supported by Hystrixcommand, except commandKey/observableExecutionMode/fallbackMethod that you can use the @DefaultProperties configuration default values.

• Commandkey: Used to identify a hystrix command, which takes the annotated method name by default. Note: Hystrix 里同一个键的唯一标识并不包括 groupKey It is recommended to take a unique one or two name, which prevents multiple methods from interacting with each other because of key duplication.

• Groupkey: A set of HYSTRIX commands that are used for statistics, reporting, default class names, and not configurable.

• Threadpoolkey: Used to identify a thread pool, in 如果没设置的话会取 groupKey many cases, methods within the same class are shared with the same thread pool, if the same property is configured on two methods that share the same thread pool, the properties of the thread pool are fixed after the first method is executed. So the property will be based on the configuration of the first executed method.

• commandproperties: The property associated with this command.

• threadpoolproperties: The properties associated with the thread pool,

• Observableexecutionmode: When the Hystrix command is packaged as a RxJava Observer asynchronous execution, this configuration specifies the mode in which Observable is executed, by default ObservableExecutionMode.EAGER , Observable will be executed immediately after being created, while the ObservableExecutionMode.EAGER mode will result in a Observable being subscribe after execution. Our common commands are performed synchronously, and this configuration item can not be configured.

• ignoreexceptions: The default Hystrix performs a fallback when an exception is caught while executing the method and counts the failure rate to modify the fuse's state, while the ignored exception is thrown directly to the outer layer, does not perform a fallback method, and does not affect the state of the fuse.

• raisehystrixexceptions: When a configuration item is included HystrixRuntimeException , all non-ignored exceptions are wrapped into hystrixruntimeexception, and configuring other kinds of exceptions seems to have no effect.

• Fallbackmethod: A fallback method that performs a fuse, error, or timeout when the method executes, and needs to keep this method consistent with the signature and return values of the Hystrix method.

• defaultfallback: The default fallback method, which does not make sense when the Fallbackmethod item is configured, and the default fallback method cannot have parameters, and the return value is the same as the return value of the Hystrix method.

Commandproperties How to configure

The Hystrix command property is made up @HystrixProperty of an array of annotations, Hystrixproperty by the name and value two properties, and the data type is a string.

The following is a grouping of all the command attributes.

Thread Isolation (Isolation)

• execution.isolation.strategy: Configure the way the request is isolated, there are threadPool (thread pool, default) and semaphore (semaphore) Two, the semaphore is efficient but the configuration is not flexible, we generally use Java The thread pool method used in the

• execution.timeout.enabled: Whether to set timeout for method execution, which is true by default.

• execution.isolation.thread.timeoutInMilliseconds: Method Execution Time-out, default value is 1000, which is 1 seconds, this value is configured according to the business scenario.

• execution.isolation.thread.interruptOnTimeout: execution.isolation.thread.interruptOnCancel : Whether to break the method when the method execution times out/is canceled. It is important to note that in the JVM we cannot force a thread to break, and if the Hystrix method does not have the logic to handle the interrupt signal, then the interrupt is ignored.

• execution.isolation.semaphore.maxConcurrentRequests: The default value is 10, this configuration entry takes execution.isolation.strategy semaphore effect when configured, and it specifies a hystrix method uses the maximum number of concurrent semaphores when the semaphore is isolated, and requests that exceed this concurrency number are rejected. The configuration of the semaphore isolation is one of the reasons why the Semaphore isolation configuration is not flexible in the previous article.

Statistical device (Metrics)

滑动窗口: The Hystrix is implemented by sliding windows, so we can understand the sliding window: A passenger sits on the window seat of a moving train, a row of erect poplar trees on both sides of the train, and as the train progresses, the roadside poplar quickly slips through the window, We use each tree to represent a request, the travel of the train to represent the passage of time, then, the train on the window is a typical sliding window, the passenger can see through the window poplar is hystrix to statistical data.

桶: Bucket is the smallest unit of Hystrix statistics for sliding window data. Similarly, the train window, when the train speed is very fast, if every tree in a window to count the data of the tree, it is obvious that the cost is very large, if the passenger will be divided into the window, the front of the train every one-tenth of the window is counted once the data, the cost is fully acceptable. The Hystrix bucket (bucket) is the concept of one of the window N points.

• metrics.rollingStats.timeInMilliseconds: This configuration entry specifies the size of the window, in MS, the default value is 1000, that is, a sliding window is the default statistic of 1s request data.

• metrics.healthSnapshot.intervalInMilliseconds: It specifies the size of each bucket in the health data statistic (affecting Hystrix), which by default is 500ms, when statistics are hystrix By metrics.rollingStats.timeInMilliseconds / metrics.healthSnapshot.intervalInMilliseconds calculating the number of buckets, the failure rate of the request within the current window is counted once every time the window slides over the interval of a bucket.

• metrics.rollingStats.numBuckets: Hystrix will summarize the result type of the command execution to a piece, use or generate a statistical chart for the upper application, this configuration item is specified, The number of buckets that the sliding window should split when generating the statistics stream. This configuration item is most easily confused with the metrics.healthSnapshot.intervalInMilliseconds number of buckets that this item affects the health data stream. This entry defaults to 10 and needs to keep this value metrics.rollingStats.timeInMilliseconds divisible.

• metrics.rollingPercentile.enabled: Whether the statistic method response time percentage, by default is true, Hystrix the average time taken by the method to 1%,10%,50%,90%,99% generate a statistical chart of the proportional requests.

• metrics.rollingPercentile.timeInMilliseconds: The window size when the percentage of response time is counted, the default is 60000, which is one minute.

• metrics.rollingPercentile.numBuckets: Statistics response time percentage when sliding window to divide the bucket, the default is 6, you need to maintain can be metrics.rollingPercentile.timeInMilliseconds divisible.

• metrics.rollingPercentile.bucketSize: When the percentage of response time is counted, the number of requests to be kept in the bucket of each sliding window, after which the request in the bucket exceeds this value, overwrites the data that was previously saved. The default value is 100, and when the statistic response percent configuration is all by default, the length of time for each bucket is 10s = 60000MS/6, but only the last 100 requested data is kept in this 10s.

Fuses (Circuit breaker)

• circuitbreaker.enabled: Whether the fuse is enabled, the default is true;

• circuitbreaker.forceopen: circuitbreaker.forceclosed: Whether to force the fuse on/off, force turn off to not think of any application of the scene, keep the default value, No configuration is required.

• circuitbreaker.requestvolumethreshold: The minimum number of requests in the time that the Fuse function window is enabled. Imagine if there is no such a limit, we configured a 50% request failure will open the fuse, window time only 3 requests, happens to two failed, then the fuse is opened, 5s of requests are quickly failed. The value of this configuration item needs to be calculated according to the interface's QPS, the value is too small to open the fuse may be wrong, the value is too large than the total number of requests in the time window, the fuse will never be triggered. The recommended setting is QPS * 窗口秒数 * 60% .

• circuitbreaker.errorthresholdpercentage: After obtaining the failure rate of the Hystrix method in the current time period through the sliding window, it is necessary to determine whether the fuse is to be turned on according to this configuration. The default value for this configuration item is 50, which means that a request that exceeds 50% in the window time fails after the fuse is turned on to quickly fail subsequent requests.

• circuitbreaker.sleepwindowinmilliseconds: When the fuse is turned on, all requests will fail quickly, but when the service returns to normal is the next problem to be faced. When the fuse is turned on, the Hystrix will release a request after a certain period of time, if the request succeeds, indicating that the service is likely to have returned to normal, then the fuse will be closed and if the request fails, the service is considered unavailable and the fuse remains open. This configuration entry specifies how long after the fuse is opened to allow one request to execute, the default value is 5000.

Others (Context/fallback)

• requestcache.enabled: Whether to enable the request result cache. The default is true, but it does not mean that each of our requests will be cached. Caching the request results and getting the results from the cache requires us to configure and cacheKey use annotations on the method to @CacheResult declare a cache context.

• requestlog.enabled: If Request log is enabled, the default is true.

• fallback.enabled: Whether to enable method fallback, which is true by default.

• fallback.isolation.semaphore.maxConcurrentRequests: The maximum concurrency when the fallback method executes, the default is 10, and if a large number of requested fallback methods are executed, requests that exceed this concurrency number are thrown REJECTED_SEMAPHORE_FALLBACKexception.

Threadpoolproperties How to configure

The thread pool configuration is also composed of hystrixproperty arrays, which are configured in the same way as command properties.

Configuration Items

• coresize: The size of the core thread pool, the default value is 10, generally based on QPS * 99% cost + redundancy count calculations.

• allowmaximumsizetodivergefromcoresize: Whether to allow the thread pool to expand to the maximum number of thread pools, default to false;

• maximumsize: The maximum number of threads in the thread pool, the default value is 10, this configuration item is configured independently and does not take effect, and the item needs to be enabled allowMaximumSizeToDivergeFromCoreSize .

• maxqueuesize: The maximum value of the job queue, the default value is-1, when set to this value, the queue is used SynchronousQueue , and its size is 0,hystrix does not store jobs in the queue. If this value is set to a positive int, the queue will use a fixed size, at which point the thread in the LinkedBlockingQueue core line Cheng is busy, and the job is temporarily stored in this queue, but requests that exceed this queue will still be rejected.

• queuesizerejectionthreshold: Because the value of the maxQueueSize online pool is fixed size, if you need to dynamically modify the queue length, you can set this value, even if the queue is not full, the job in the queue to reach this value will also deny the request. This value defaults to 5, so it is sometimes only set and maxQueueSize will not work.

• keepalivetimeminutes: By the above maximumSize , we know that the number of core threads in the thread pool is busy, and when a new request arrives, the thread pool capacity can be expanded to the maximum number of threads, and when the thread pool is idle, more than the core number will be recycled , this value specifies the time to live before the thread is recycled, which defaults to 2, or two minutes.

Working style

The use of the Hystrix thread pool is a simple wrapper based on the Java built-in thread pool, usually in the following three states:

• If the number of requests is less than coresize, the core thread is typically used to perform the task.
• If set maxQueueSize , when the number of requests exceeds coresize, the request is usually placed in the queue, waiting for the core thread to consume when it is idle.
• If the queue length cannot store the request, a new thread is created to execute until the maximumSize maximum number of threads is reached, and the threads that have more core threads are reclaimed at idle time.

Summary

Troubleshooting the configuration problem itself is also a learning process, understand the process of Hystrix source code also learned a lot of Java thread pool related knowledge, ah, harvest is not small.

About this article has any questions can be in the following message exchange, if you think this article is helpful to you, 推荐 You can click on the following support me, blog 关注 has been updated, welcome.