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

This article introduces what is the Spring Cloud timeout and retry mechanism, the content is very detailed, interested friends can use for reference, I hope it can be helpful to you.

This paper is based on Spring Cloud Greenwich.SR2 and Spring Boot 2.1.6.RELEASE.

1. Feign configuration 1.1 timeout feign: client: config: default: connect-timeout: 2000 read-timeout: 20001.2 retry

Spring Cloud turns off Feign's retry mechanism by default

/ / org.springframework.cloud.openfeign.FeignClientsConfiguration@Bean@ConditionalOnMissingBeanpublic Retryer feignRetryer () {return Retryer.NEVER_RETRY;} / / feign.Retryer/** * Implementation that never retries request. It propagates the RetryableException. * / Retryer NEVER_RETRY = new Retryer () {@ Override public void continueOrPropagate (RetryableException e) {throw e;} @ Override public Retryer clone () {return this;}}

If you want to open it, declare a bean yourself.

@ Beanpublic Retryer feignRetryer () {return new Retryer.Default () } II. Configuration of Ribbon 2.1 timeout # timeout of ribbon # if both ribbon and feign timeout are configured The configuration of ribbon will be overwritten ribbon: ReadTimeout: 3000 ConnectTimeout: 30002.2 retry ribbon: MaxAutoRetries: 1 # maximum number of retries for the same instance, excluding the maximum number of retries of other instances when MaxAutoRetriesNextServer: 1 # is called for the first time Does not include whether all operations are retried when calling OkToRetryOnAllOperations: false # for the first time. III. Hystrix configuration 3.1 timeout hystrix: command: default: execution: timeout: enabled: true isolation: thread: timeoutInMilliseconds: 1000

Note that the timeout of Hystrix should exceed the retry time of ribbon, otherwise, during the retry of ribbon, Hystrix will be triggered first.

For timeout calculation, please refer to the getRibbonTimeout () method of the AbstractRibbonCommand class in zuul.

Protected static int getRibbonTimeout (IClientConfig config, String commandKey) {int ribbonTimeout; / / this is an unusual situation, not to mention if (config = = null) {ribbonTimeout = RibbonClientConfiguration.DEFAULT_READ_TIMEOUT + RibbonClientConfiguration.DEFAULT_CONNECT_TIMEOUT } else {/ / four parameters are obtained here: ReadTimeout,ConnectTimeout,MaxAutoRetries, MaxAutoRetriesNextServer int ribbonReadTimeout = getTimeout (config, commandKey, "ReadTimeout", IClientConfigKey.Keys.ReadTimeout, RibbonClientConfiguration.DEFAULT_READ_TIMEOUT); int ribbonConnectTimeout = getTimeout (config, commandKey, "ConnectTimeout", IClientConfigKey.Keys.ConnectTimeout, RibbonClientConfiguration.DEFAULT_CONNECT_TIMEOUT) Int maxAutoRetries = getTimeout (config, commandKey, "MaxAutoRetries", IClientConfigKey.Keys.MaxAutoRetries, DefaultClientConfigImpl.DEFAULT_MAX_AUTO_RETRIES); int maxAutoRetriesNextServer = getTimeout (config, commandKey, "MaxAutoRetriesNextServer", IClientConfigKey.Keys.MaxAutoRetriesNextServer, DefaultClientConfigImpl.DEFAULT_MAX_AUTO_RETRIES_NEXT_SERVER) / / the calculation method of ribbonTimeout is here, take the above settings as an example / / ribbonTimeout = (3000 + 3000) * (1 + 1) * (1 + 1) = 24000 (millisecond) ribbonTimeout = (ribbonReadTimeout + ribbonConnectTimeout) * (maxAutoRetries + 1) * (maxAutoRetriesNextServer + 1);} return ribbonTimeout;} IV, RestTemplate configuration 4.1 timeout

The default timeout for RestTemplate is-1, which means it will not time out. If you want to set it, you can do so.

@ Bean@Primary@LoadBalancedpublic RestTemplate lbRestTemplate () {SimpleClientHttpRequestFactory simpleClientHttpRequestFactory = new SimpleClientHttpRequestFactory (); simpleClientHttpRequestFactory.setConnectTimeout (1000); simpleClientHttpRequestFactory.setReadTimeout (1000); return new RestTemplate (simpleClientHttpRequestFactory);} V. Feign call process source code analysis 5.1 OKToRetryOnAllOperations parameter meaning / / AbstractLoadBalancerAwareClient.javapublic T executeWithLoadBalancer (final S request, final IClientConfig requestConfig) throws ClientException {LoadBalancerCommand command = buildLoadBalancerCommand (request, requestConfig) / / omit...} protected LoadBalancerCommand buildLoadBalancerCommand (final S request, final IClientConfig config) {RequestSpecificRetryHandler handler = getRequestSpecificRetryHandler (request, config); / / omit.} / / FeignLoadBalancer.java//FeignLoadBalancer is a subclass of AbstractLoadBalancerAwareClient @ Overridepublic RequestSpecificRetryHandler getRequestSpecificRetryHandler (RibbonRequest request, IClientConfig requestConfig) {/ / if the isOkToRetryOnAllOperations parameter is true if (this.ribbon.isOkToRetryOnAllOperations ()) {return new RequestSpecificRetryHandler (true, true, this.getRetryHandler (), requestConfig) } if (! request.toRequest (). HttpMethod (). Name (). Equals ("GET")) {return new RequestSpecificRetryHandler (true, false, this.getRetryHandler (), requestConfig);} else {return new RequestSpecificRetryHandler (true, true, this.getRetryHandler (), requestConfig) }} / / RequestSpecificRetryHandler.java/** * okToRetryOnConnectErrors: retry only for connection errors * okToRetryOnAllErrors: retry is initiated for all errors * / public RequestSpecificRetryHandler (boolean okToRetryOnConnectErrors, boolean okToRetryOnAllErrors, RetryHandler baseRetryHandler, @ Nullable IClientConfig requestConfig) {Preconditions.checkNotNull (baseRetryHandler); this.okToRetryOnConnectErrors = okToRetryOnConnectErrors; this.okToRetryOnAllErrors = okToRetryOnAllErrors; this.fallback = baseRetryHandler If (requestConfig! = null) {if (requestConfig.containsProperty (CommonClientConfigKey.MaxAutoRetries)) {retrySameServer = requestConfig.get (CommonClientConfigKey.MaxAutoRetries);} if (requestConfig.containsProperty (CommonClientConfigKey.MaxAutoRetriesNextServer)) {retryNextServer = requestConfig.get (CommonClientConfigKey.MaxAutoRetriesNextServer);}

You can see that if isOkToRetryOnAllOperations is set to true, all errors will be retried, otherwise only the connection exception will be retried. The code to determine whether to retry is as follows:

/ / RequestSpecificRetryHandler.java@Overridepublic boolean isRetriableException (Throwable e, boolean sameServer) {if (okToRetryOnAllErrors) {return true;} else if (e instanceof ClientException) {ClientException ce = (ClientException) e; if (ce.getErrorType () = = ClientException.ErrorType.SERVER_THROTTLED) {return! sameServer;} else {return false }} else {return okToRetryOnConnectErrors & & isConnectionException (e);}}

There will be a problem, if you are adding / modifying operations, the system processing time is too long to lead to timeout, will also trigger the automatic retry of Feign, if you do not do well idempotent, it will lead to serious consequences.

If the connection is abnormal, the request has not been sent at this time, so it will not be repeated.

Of course, in distributed systems, it is recommended that each interface be idempotent.

5.2 Feign retry logic / / SynchronousMethodHandler.java@Overridepublic Object invoke (Object [] argv) throws Throwable {RequestTemplate template = buildTemplateFromArgs.create (argv); / / here we assume that you turn on the retry of Feign and use the class Retryer.Default Retryer retryer = this.retryer.clone (); while (true) {try {/ / Section 5.3 executeWithLoadBalancer () method return executeAndDecode (template) will be called here } catch (RetryableException e) {try {/ / within the number of retries, will wait for a period of time to return and continue the while loop, otherwise an exception will be thrown to jump out of the loop retryer.continueOrPropagate (e);} catch (RetryableException th) {Throwable cause = th.getCause () If (propagationPolicy = = UNWRAP & & cause! = null) {throw cause;} else {throw th;}} if (logLevel! = Logger.Level.NONE) {logger.logRetry (metadata.configKey (), logLevel);} continue Ribbon retry logic / / AbstractLoadBalancerAwareClient.javapublic T executeWithLoadBalancer (final S request, final IClientConfig requestConfig) throws ClientException {LoadBalancerCommand command = buildLoadBalancerCommand (request, requestConfig); try {return command.submit (new ServerOperation () {@ Override public Observable call (Server server) {URI finalUri = reconstructURIWithServer (server, request.getUri ()) S requestForServer = (S) request.replaceUri (finalUri); try {return Observable.just (AbstractLoadBalancerAwareClient.this.execute (requestForServer, requestConfig));} catch (Exception e) {return Observable.error (e) ) .toBlocking () .single ();} catch (Exception e) {Throwable t = e.getCause (); if (t instanceof ClientException) {throw (ClientException) t;} else {throw new ClientException (e);}

The above is the entry of the call, and the following is the logic of retry execution. Because it was written by RxJava, I can't understand it for the time being.

/ / LoadBalancerCommand.javapublic Observable submit (final ServerOperation operation) {final ExecutionInfoContext context = new ExecutionInfoContext (); if (listenerInvoker! = null) {try {listenerInvoker.onExecutionStart ();} catch (AbortExecutionException e) {return Observable.error (e);}} final int maxRetrysSame = retryHandler.getMaxRetriesOnSameServer (); final int maxRetrysNext = retryHandler.getMaxRetriesOnNextServer () / / Use the load balancer Observable o = (server = = null? SelectServer (): Observable.just (server) .concatMap (new Func1 () {@ Override / / Called for each server being selected public Observable call (Server server) {context.setServer (server); final ServerStats stats = loadBalancerContext.getServerStats (server)) / / Called for each attempt and retry Observable o = Observable .just (server) .concatMap (new Func1 () {@ Override public Observable call (final Server server) {context.incAttemptCount () LoadBalancerContext.noteOpenConnection (stats); if (listenerInvoker! = null) {try {listenerInvoker.onStartWithServer (context.toExecutionInfo ()) } catch (AbortExecutionException e) {return Observable.error (e);}} final Stopwatch tracer = loadBalancerContext.getExecuteTracer () .start () Return operation.call (server) .doonEach (new Observer () {private T entity; @ Override public void onCompleted () {recordStats (tracer, stats, entity, null) / / TODO: What to do if onNext or onError are never called?} @ Override public void onError (Throwable e) {recordStats (tracer, stats, null, e) Logger.debug ("Got error {} when executed on server {}", e, server); if (listenerInvoker! = null) {listenerInvoker.onExceptionWithServer (e, context.toExecutionInfo ()) } @ Override public void onNext (T entity) {this.entity = entity If (listenerInvoker! = null) {listenerInvoker.onExecutionSuccess (entity, context.toExecutionInfo ()) }} private void recordStats (Stopwatch tracer, ServerStats stats, Object entity, Throwable exception) {tracer.stop () LoadBalancerContext.noteRequestCompletion (stats, entity, exception, tracer.getDuration (TimeUnit.MILLISECONDS), retryHandler);}}) If (maxRetrysSame > 0) o = o.retry (retryPolicy (maxRetrysSame, true)); return o;}}); if (maxRetrysNext > 0 & & server = = null) o = o.retry (retryPolicy (maxRetrysNext, false)) Return o.onErrorResumeNext (new Func1 () {@ Override public Observable call (Throwable e) {if (context.getAttemptCount () > 0) {if (maxRetrysNext > 0 & & context.getServerAttemptCount () = = (maxRetrysNext + 1)) {e = new ClientException (ClientException.ErrorType.NUMBEROF_RETRIES_NEXTSERVER_EXCEEDED) "Number of retries on next server exceeded max" maxRetrysNext + "retries, while making a call for:" + context.getServer (), e) } else if (maxRetrysSame > 0 & & context.getAttemptCount () = = (maxRetrysSame + 1)) {e = new ClientException (ClientException.ErrorType.NUMBEROF_RETRIES_EXEEDED, "Number of retries exceeded max" + maxRetrysSame + "retries) While making a call for: "+ context.getServer (), e) }} if (listenerInvoker! = null) {listenerInvoker.onExecutionFailed (e, context.toFinalExecutionInfo ();} return Observable.error (e);}}) } about the Spring Cloud timeout and retry mechanism is shared here, I hope the above content can be of some help to you, can learn more knowledge. If you think the article is good, you can share it for more people to see.

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.