SpringCloud retry mechanism configuration
First of all, the retry here is not a retry after an error is reported, but a retry to another instance after the load balancing client finds that the remote request instance is unavailable.
@Bean@LoadBalancedRestTemplate restTemplate() { HttpComponentsClientHttpRequestFactory httpRequestFactory = new HttpComponentsClientHttpRequestFactory(); httpRequestFactory.setReadTimeout(5000); httpRequestFactory.setConnectTimeout(5000); return new RestTemplate(httpRequestFactory);}feign retry mechanism
feign is retrying the configuration through the Retryer packaged by itself, and the default is 5 times
package feign;import static java.util.concurrent.TimeUnit.SECONDS;/** * Cloned for each invocation to {@link Client#execute(Request, feign.Request.Options)}. * Implementations may keep state to determine if retry operations should continue or not. */public interface Retryer extends Cloneable { /** * if retry is permitted, return (possibly after sleeping). Otherwise propagate the exception. */ void continueOrPropagate(RetryableException e); Retryer clone(); public static class Default implements Retryer { private final int maxAttempts; private final long period; private final long maxPeriod; int attempt; long sleptForMillis; public Default() { this(100, SECONDS.toMillis(1), 5); } public Default(long period, long maxPeriod, int maxAttempts) { this.period = period; this.maxPeriod = maxPeriod; this.maxAttempts = maxAttempts; this.attempt = 1; }feign Cancel Retry
@BeanRetryer feignRetryer() {return Retryer.NEVER_RETRY;}feign request timeout setting
@BeanRequest.Options requestOptions(ConfigurableEnvironment env){ int ribbonReadTimeout = env.getProperty("ribbon.ReadTimeout", int.class, 6000); int ribbonConnectionTimeout = env.getProperty("ribbon.ConnectTimeout", int.class, 3000); return new Request.Options(ribbonConnectionTimeout, ribbonReadTimeout);}Retry of each component in Spring Cloud
Recently, many children's shoes have asked me how to configure the Spring Cloud xxx component to try again. This article summarizes it.
The retry mechanism in Spring Cloud is quite chaotic. Different versions have certain differences and the implementation is not very different. Fortunately, Spring Cloud Camden has basically stabilized after it, and some improvements have been made in Dalston. The details are not specified yet.
Let's discuss it in detail below.
The version I use is Spring Cloud Dalston SR4, which is also suitable for Edgware and later. For Dalston's previous version, this article will not discuss it, you can study it yourself.
Retry of Ribbon+RestTemplate
For the RestTemplate that integrates Ribbon, for example, a RestTemplate adds the @LoadBalanced annotation:
@Bean@LoadBalancedpublic RestTemplate restTemplate() { SimpleClientHttpRequestFactory simpleClientHttpRequestFactory = new SimpleClientHttpRequestFactory(); simpleClientHttpRequestFactory.setConnectTimeout(1000); simpleClientHttpRequestFactory.setReadTimeout(1000); return new RestTemplate(simpleClientHttpRequestFactory);}On this basis, retry can be achieved using the following configuration:
spring: cloud: loadbalancer: retry: enabled: trueribbon: # Maximum number of retries for the same instance, excluding the first call to MaxAutoRetries: 1 # Maximum number of retries for other instances, excluding the first selected server MaxAutoRetriesNextServer: 2 # Whether all operations are retries OkToRetryOnAllOperations: false
Feign's retry
Feign itself also has the ability to retry. In the early Spring Cloud, Feign used feign.Retryer.Default#Default() , and tried it 5 times. But Feign integrates Ribbon, and Ribbon also has the ability to retry, which may lead to confusion in behavior at this time.
Spring Cloud realized this problem, so it made improvements to change Feign's retry to feign.Retryer#NEVER_RETRY . If you need to use Feign's retry, just use Ribbon's retry configuration. Therefore, for Camden and later versions, Feign's retry can be configured using the following properties:
ribbon: MaxAutoRetries: 1 MaxAutoRetriesNextServer: 2 OkToRetryOnAllOperations: false
Related Issues can be found at: https://github.com/spring-cloud/spring-cloud-netflix/issues/467
Zuul's retry
Configuration:
zuul: # Enable Zuul's retryable retryable: trueribbon: MaxAutoRetries: 1 MaxAutoRetriesNextServer: 2 OkToRetryOnAllOperations: false
Above we used zuul.retryable=true to enable retry globally on Zuul. In fact, we can also enable/off the specified route:
zuul.routes.<routename>.retryable=true
Local configuration priority is higher.
Retry based on HTTP response code
clientName: ribbon: retryableStatusCodes: 404,502
Note:
The timeout of Hystrix must be greater than the timeout time, otherwise, once Hystrix timeout, there is no way to continue to try again.
Generally speaking, it is not recommended to set ribbon.OkToRetryOnAllOperations to true. Because once this configuration is enabled, any operation is retryed, including POST requests, and since the request body is cached, the resources of the server may be affected at this time.
Summarize
The above is the entire content of this article. I hope that the content of this article has certain reference value for everyone's study or work. If you have any questions, you can leave a message to communicate. Thank you for your support to Wulin.com.