Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

How to use hystrix parameter in SpringCloud

2025-02-23 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Internet Technology >

Share

Shulou(Shulou.com)06/01 Report--

This article mainly introduces how to use the hystrix parameter in SpringCloud. It is very detailed and has a certain reference value. Friends who are interested must read it!

1. How to use hystrix parameters

Configure by annotating the commandProperties of @ HystrixCommand

The following is the hystrix command timeout. The timeout is not enabled for 1000ms and execution.

@ RestControllerpublic class MovieController {@ Autowired private RestTemplate restTemplate GetMapping ("/ movie/ {id}") @ HystrixCommand (commandProperties = {@ HystrixProperty (name = "execution.isolation.thread.timeoutInMilliseconds", value = "1000"), @ HystrixProperty (name = "execution.timeout.enabled", value = "false")}, fallbackMethod = "findByIdFallback") public User findById (@ PathVariable Long id) {return this.restTemplate.getForObject ("http://microservice-provider-user/simple/" + id, User.class) } / * fallback method * @ param id * @ return * / public User findByIdFallback (Long id) {User user = new User (); user.setId (5L); return user;}}

2. Hystrix parameters are as follows

Default in hystrix.command.default and hystrix.threadpool.default is the configuration of default CommandKey Command PropertiesExecution related attributes: hystrix.command.default.execution.isolation.strategy isolation policy, default is Thread, optional Thread | timeout of Semaphore hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds command execution, whether timeout is enabled for 1000ms hystrix.command.default.execution.timeout.enabled execution by default, whether timeout occurs when truehystrix.command.default.execution.isolation.thread.interruptOnTimeout is enabled by default The default maximum number of concurrent requests for truehystrix.command.default.execution.isolation.semaphore.maxConcurrentRequests is 10. This parameter is valid only when the ExecutionIsolationStrategy.SEMAPHORE policy is used. If the maximum number of concurrent requests is reached, the request is rejected. Theoretically, the principle of choosing semaphore size is the same as choosing thread size, but when choosing semaphore, each execution unit should be relatively small and fast (ms level), otherwise thread should be used. Semaphore should be a small part of the thread pool of the entire container (tomcat). Properties related to Fallback these parameters can be applied to Hystrix's THREAD and SEMAPHORE policy hystrix.command.default.fallback.isolation.semaphore.maxConcurrentRequests if the number of concurrency reaches this set value, the request will be rejected and an exception will be thrown and the fallback will not be called. Default 10hystrix.command.default.fallback.enabled whether to attempt to call hystrixCommand.getFallback () when execution fails or the request is rejected. The default trueCircuit Breaker-related attribute, hystrix.command.default.circuitBreaker.enabled, is used to track the health of the circuit and short-circuit the request if it is not up to standard. Default truehystrix.command.default.circuitBreaker.requestVolumeThreshold the minimum number of requests in a rolling window. If set to 20, circuit break will not be triggered when 19 requests are received within a rolling window time (for example, 1 rolling window is 10 seconds), even if 19 requests fail. The default time when 20hystrix.command.default.circuitBreaker.sleepWindowInMilliseconds triggers a short circuit. When this value is set to 5000, request will be rejected within 5000 milliseconds after circuit break is triggered, that is, 5000 milliseconds before circuit will be closed. Default 5000hystrix.command.default.circuitBreaker.errorThresholdPercentage error rate threshold, if the error rate > = this value, circuit will be opened and short-circuited all requests trigger fallback. The default 50hystrix.command.default.circuitBreaker.forceOpen forces fuses to be turned on. If this switch is turned on, all request is rejected. By default, falsehystrix.command.default.circuitBreaker.forceClosed forces fuses to be turned off. If this switch is turned on, circuit will always turn off and ignore the time window value of circuitBreaker.errorThresholdPercentageMetrics related parameters hystrix.command.default.metrics.rollingStats.timeInMilliseconds setting statistics. The opening of circuit break will be calculated according to the statistics of 1 rolling window. If rolling window is set to 10000 milliseconds, rolling window is divided into n buckets, and each bucket contains statistics on the number of success,failure,timeout,rejection. The default 10000hystrix.command.default.metrics.rollingStats.numBuckets sets the number of rolling window partitions. If numBuckets=10,rolling window=10000, the time of a bucket is 1 second. Must conform to rolling window% numberBuckets = = 0. Whether the default 10hystrix.command.default.metrics.rollingPercentile.enabled executes the calculation and tracking of enable metrics, the default truehystrix.command.default.metrics.rollingPercentile.timeInMilliseconds sets the time of rolling percentile window, and the default 60000hystrix.command.default.metrics.rollingPercentile.numBuckets sets the numberBuckets of rolling percentile window. The logic is the same. If the default 6hystrix.command.default.metrics.rollingPercentile.bucketSize is bucket size=100,window=10s, if there are 500 executes in these 10s, only the last 100 executions will be counted in bucket. Increasing this value increases memory overhead and sorting overhead. Default 100hystrix.command.default.metrics.healthSnapshot.intervalInMilliseconds records the interval between health snapshots (used to count success and error green). Default 500msRequest Context related parameter hystrix.command.default.requestCache.enabled default true, which requires overloading getCacheKey (). When null is returned, hystrix.command.default.requestLog.enabled logs are not cached to HystrixRequestLog. By default, the maximum number of requests for a single batch processing of true Collapser Properties related parameter hystrix.collapser.default.maxRequestsInBatch reaches this number to trigger batch processing. The default Integer.MAX_VALUEhystrix.collapser.default.timerDelayInMilliseconds triggers the delay of the batch, or you can add this value for the time when the batch was created. Whether the default 10hystrix.collapser.default.requestCache.enabled is for the cache of HystrixCollapser.execute () and HystrixCollapser.queue (), the default value of 10 for the number of threads related to true ThreadPool is suitable for most cases (sometimes it can be set to a smaller value). If you need to set it to a larger value, There is a basic formula for follow:requests per second at peak when healthy × 99th percentile latency in seconds + some breathing room maximum number of requests per second (99% average response time + cache value) for example: 1000 requests per second can be processed, 99% of the request response time is 60ms, then the formula is: (0.060-0.012) the basic principle is to keep the thread pool as small as possible, mainly to relieve pressure and prevent resources from being blocked. When everything is normal, the thread pool generally has only one or two threads activated to provide service hystrix.threadpool.default.coreSize the maximum number of threads for concurrent execution. The default maximum number of queues for 10hystrix.threadpool.default.maxQueueSize BlockingQueue, when set to-1, uses SynchronousQueue, and uses LinkedBlcokingQueue when the value is positive. This setting is only valid at initialization, and the queue size of threadpool cannot be modified after that, unless reinitialising thread executor. The default is-1. Hystrix.threadpool.default.queueSizeRejectionThreshold even if the maxQueueSize is not reached, the request will be rejected when the queueSizeRejectionThreshold value is reached. Because maxQueueSize cannot be dynamically modified, this parameter will allow us to set the value dynamically. If maxQueueSize =-1, this field will not work hystrix.threadpool.default.keepAliveTimeMinutes if corePoolSize and maxPoolSize are set to the same (default implementation) this setting is invalid. This setting is only useful if you use a custom implementation through plugin (https://github.com/Netflix/Hystrix/wiki/Plugins). The default 1.hystrix.threadpool.default.metrics.rollingStats.timeInMilliseconds thread pool statistics indicator time, the default 10000hystrix.threadpool.default.metrics.rollingStats.numBuckets divides rolling window into n buckets, and the default above 10 is all the contents of the article "how to use hystrix parameters in SpringCloud". Thank you for reading! Hope to share the content to help you, more related knowledge, welcome to follow the industry information channel!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.

Views: 0

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Internet Technology

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report