当前位置:网站首页>Full resolution of hystrix configuration parameters

Full resolution of hystrix configuration parameters

2021-09-15 05:07:42 fhspringcloud

Preface


Not long ago, I shared at the Department weekly meeting Hystrix After analyzing the source code , He was helpless to carry the burden of experts , My colleagues think I'm right Hystrix Very familiar , We touch Hystrix More is the use and configuration at work , So many people encounter Hystrix The configuration problem will come and ask me . In order not to disappoint them , I put Hystrix Of   The configuration document   Have a close look at , Pass the questionable points through the source code 、 Check the official issue、 I sorted out the way of my own experiment , That's right Hystrix Have a certain understanding of the configuration of .

In the process of understanding these configuration items , I also found a lot of pits , Normally, the values we take for granted do not make Hystrix Work on schedule , Copying and pasting the configuration without consideration will make Hystrix It will never work . So write this article , I hope I can help my friends master Hystrix.

HystrixCommand


Configuration mode

Our configuration is based on HystrixCommand Of , We add them by adding them to the method  @HystrixCommand  Annotate and configure the annotation's parameters to implement the configuration , But sometimes there are more than one in a class Hystrix Method , If each method is configured in a similar way, there will be a lot of redundant code , At this point we can use it on the class  @DefaultProperties  Comments for the entire class Hystrix Method sets a default value .

Configuration item

Here is HystrixCommand Supported parameters , except  commandKey/observableExecutionMode/fallbackMethod  Outside , You can use  @DefaultProperties  Configure defaults .

  • commandKey: To identify a Hystrix command , By default, the annotated method name is taken . We need to pay attention to :Hystrix The unique identification of the same key is not included groupKey, Suggest a unique name , Prevent multiple methods from interacting with each other because of duplicate keys .

  • groupKey: A group of Hystrix Collection of commands , Used for statistical 、 The report , The class name is taken by default , Don't configuration .

  • threadPoolKey: Identifies a thread pool , If it's not set, it will groupKey, In many cases, methods within the same class share the same thread pool , If the same properties are configured on two methods that share the same thread pool , The thread pool property is fixed after the first method is executed , So the properties are configured on the method that was first executed .

  • commandProperties: Properties associated with this command .

  • threadPoolProperties: Properties related to thread pools ,

  • observableExecutionMode: When Hystrix The command is packaged as RxJava Of Observer Asynchronous execution , This configuration is specified Observable The pattern being executed , The default is  ObservableExecutionMode.EAGER,Observable It will be executed immediately after it is created , and  ObservableExecutionMode.EAGER In mode , There's going to be one Observable By subscribe After execution . Our common commands are executed synchronously , This configuration item may not be configured .

  • ignoreExceptions: Default Hystrix A fallback is performed when an exception is caught while executing a method , The failure rate is calculated to modify the state of the fuse , Exceptions that are ignored are thrown directly into the outer layer , A fallback method is not executed , It will not affect the state of the fuse .

  • raiseHystrixExceptions: When the configuration item is included  HystrixRuntimeException  when , All exceptions that are not ignored are wrapped HystrixRuntimeException, Does configuring other kinds of exceptions seem to have no effect .

  • fallbackMethod: Method is fused during execution 、 error 、 A fallback method that executes when a timeout occurs , This method needs to be maintained with Hystrix The method's signature is the same as the return value .

  • defaultFallback: Default fallback method , When configuring fallbackMethod This term doesn't make sense , in addition , The default fallback method cannot have arguments , The return value is to be associated with Hystrix Method returns the same value .

commandProperties


Configuration mode

Hystrix The command properties of  @HystrixProperty  Annotation array ,HystrixProperty from name and value Two attributes , Data types are strings .

All the command properties are grouped below .

Microservices to    fhadmin.cn

Thread isolation (Isolation)

  • execution.isolation.strategy: Configure how requests are isolated , Yes threadPool( Thread pool , Default ) and semaphore( Semaphore ) Two kinds of , The semaphore approach is efficient but not flexible , We usually use Java Common thread pool in the way .

  • execution.timeout.enabled: Whether to set a timeout for method execution , The default is true.

  • execution.isolation.thread.timeoutInMilliseconds: Method execution timeout , The default value is 1000, namely 1 second , This value is configured according to the business scenario .

  • execution.isolation.thread.interruptOnTimeout: execution.isolation.thread.interruptOnCancel: Whether the method is timed out / Interrupt method when cancelled . It is important to note that JVM We cannot force a thread to break , If Hystrix Method has no logic to handle interrupt signals , Then the interrupt will be ignored .

  • execution.isolation.semaphore.maxConcurrentRequests: The default value is 10, This configuration item will be displayed in the  execution.isolation.strategy  Configure to  semaphore  Will not take effect until , It specifies one Hystrix Method USES the maximum number of concurrences in semaphore isolation , Requests exceeding this number of concurrences are rejected . There is only one configuration for semaphore isolation , This is also the reason why the semaphore isolation configuration is not flexible .

Statistical machine (Metrics)

The sliding window : Hystrix Is implemented by sliding Windows , We can think of sliding Windows this way : A passenger was sitting in a window seat on a moving train , On either side of the road where the train was running was a row of tall poplar trees , As the train goes , The poplar trees on the side of the road slid quickly past the window , We use each tree to represent a request , The passage of time is represented by the running of the train , that , This window on the train is a typical sliding window , The poplar tree that the passenger could see through the window was Hystrix The data to be counted .

bucket : bucket yes Hystrix The smallest unit of statistics for sliding window data . Again, train Windows , When the train is going very fast , If you count the tree in the window for every tree that passes by , It's obviously very expensive , If the passenger divides the window into 10 points , Statistics are collected for every tenth of the window that passes in front of the train , The cost is perfectly acceptable . Hystrix Of bucket ( bucket ) That's the window N One of the points The concept of .

  • metrics.rollingStats.timeInMilliseconds: This configuration item specifies the size of the window , The unit is ms, The default value is 1000, That is, the default statistics of a sliding window is 1s Request data within .

  • metrics.healthSnapshot.intervalInMilliseconds: It specifies the health data statistician ( influence Hystrix Fuse ) The size of each bucket , The default is 500ms, When you do the statistics ,Hystrix adopt  metrics.rollingStats.timeInMilliseconds / metrics.healthSnapshot.intervalInMilliseconds  Calculate the number of barrels , When the window slides , The failure rate of requests in the current window is counted for each time interval that a bucket is slid over .

  • metrics.rollingStats.numBuckets:Hystrix The result types of command execution are aggregated into a single statistic , Use or generate statistical charts for upper level applications , This configuration item is specified , The number of buckets that the sliding window should split when generating a stream of statistics . This configuration item is the easiest to follow  metrics.healthSnapshot.intervalInMilliseconds  Mix up , This is considered to affect the number of barrels of health data stream . The default is 10, And you need to keep this value available  metrics.rollingStats.timeInMilliseconds  to be divisible by .

  • metrics.rollingPercentile.enabled: Whether the method response time percentage is counted , The default is true when ,Hystrix The statistical method will be executed  1%,10%,50%,90%,99%  The average time spent on equal-proportion requests is used to generate statistical charts .

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

  • metrics.rollingPercentile.numBuckets: The percentage of response time is calculated when the bucket to be divided by the sliding window , The default is 6, Need to keep being able to be metrics.rollingPercentile.timeInMilliseconds  to be divisible by .

  • metrics.rollingPercentile.bucketSize: When the response time percentage is counted , The number of requests to be kept in the bucket of each sliding window , After the request in the bucket exceeds this value , Overwrites the data that was saved first . The default value is 100, When the statistics response percentage configuration is all default , The time length of each bucket is 10s = 60000ms / 6, But this 10s Keep only the nearest ones inside 100 The requested data .

Fuse (Circuit Breaker)

  • circuitBreaker.enabled: Whether to enable fuse , The default is true;

  • circuitBreaker.forceOpen: circuitBreaker.forceClosed: Mandatory or not / Turn off the fuse , Scenarios where you can't think of an application to force on or off , Keep the default , No configuration is ok .

  • circuitBreaker.requestVolumeThreshold: Minimum number of requests during the fuse function window . Imagine if there were no such restriction , We've configured 50% Failure to do so will open the fuse , Only in window time 3 The request , Both failed , Then the fuse is turned on ,5s All requests within were quickly failed . The value of this configuration item needs to be based on the interface QPS Calculate , If the value is too small, it may cause an error to open the fuse , The value is too large for the total number of requests in the time window , The circuit breaker will never be triggered . Recommended setting is  QPS * Window number of seconds * 60%.

  • circuitBreaker.errorThresholdPercentage: Within the current time period obtained by sliding the window Hystrix Method execution after failure rate , You will need this configuration to determine whether to open the fuse . The default value for this configuration item is 50, That is, the window time is exceeded 50% If the request fails, the fuse will be opened and the subsequent request will fail quickly .

  • circuitBreaker.sleepWindowInMilliseconds: When the fuse is open , All requests fail quickly , But when service returns to normal is the next question . When the fuse is on ,Hystrix A request is released after a period of time , If the request is executed successfully , Indicates that the service is most likely back to normal at this point , That will shut off the fuse , If this request fails to execute , The service is considered still unavailable , The fuse remains open . This configuration item specifies how long after the fuse is opened to allow a request to attempt execution , The default value is 5000.

other (Context/Fallback)

  • requestCache.enabled: Whether to enable the request result cache . The default is true, But it doesn't mean that every request we make will be cached . Caching the request result and getting the result from the cache both require configuration  cacheKey, And use it methodically  @CacheResult  Annotations declare a cache context .

  • requestLog.enabled: Whether the request log is enabled , The default is true.

  • fallback.enabled: Whether to enable method fallback , The default is true that will do .

  • fallback.isolation.semaphore.maxConcurrentRequests: The maximum number of concurrent executions of the fallback method , The default is 10, If a large number of requests for a fallback method are executed , Requests exceeding this number of concurrences are thrown  REJECTED_SEMAPHORE_FALLBACK  abnormal .

threadPoolProperties


Configuration mode

The configuration of the thread pool is also by HystrixProperty Array composition , The configuration is consistent with the command properties .

Configuration item

  • coreSize: The size of the core thread pool , The default value is 10, According to the general  QPS * 99% cost + redundancy count  calculated .

  • allowMaximumSizeToDivergeFromCoreSize: Whether thread pools are allowed to expand to the maximum number of thread pools , The default is false;

  • maximumSize: The maximum number of threads in a thread pool , The default value is 10, This configuration item does not take effect when configured separately , You need to enable  allowMaximumSizeToDivergeFromCoreSize term .

  • maxQueueSize: The maximum value of the job queue , The default value is -1, When this value is set , The queue will use  SynchronousQueue, At this point the size by 0,Hystrix Jobs are not stored in the queue . If this value is set to a positive int type , The queue will use a fix size Of  LinkedBlockingQueue, When all the threads in the core thread pool are busy , Jobs are temporarily stored in this queue , Requests beyond this queue will still be rejected .

  • queueSizeRejectionThreshold: because  maxQueueSize  The value is fixed in size after the thread pool is created , This value can be set if the queue length needs to be changed dynamically , Even if the queue is not full , When a job in the queue reaches this value, the request is also rejected . This value defaults to 5, So sometimes it's just set  maxQueueSize  It won't work .

  • keepAliveTimeMinutes: By the above  maximumSize, We know , The number of core threads in the thread pool is busy , There are new requests when they arrive , The thread pool capacity can be expanded to the maximum number , Wait until the thread pool is free , More threads than the number of cores are recycled , This value specifies how long the thread lives before it is recycled , The default is 2, The two minutes .

Operation mode

Hystrix The use of internal thread pools is based on Java A simple wrapper around the built-in thread pool , There are usually three states :

  • If the number of requests is small , To reach coreSize, Core threads are often used to perform tasks .

  • If set  maxQueueSize, When the number of requests exceeds coreSize, The request is usually put in queue in , Consume when the core thread is free .

  • If queue Length cannot store request , A new thread is created to execute until it reaches  maximumSize  Maximum number of threads , Threads with more core threads are recycled at idle .

版权声明
本文为[fhspringcloud]所创,转载请带上原文链接,感谢
https://chowdera.com/2021/09/20210909115113521l.html

随机推荐