SpringCloud | FeignClient和Ribbon重试机制区别与联系

闻道☞

已于 2022-02-24 16:56:44 修改

阅读量3.7k

点赞数 2

分类专栏： Spring Cloud 文章标签： ribbon spring cloud java

于 2020-05-19 14:39:43 首次发布

原文链接：https://blog.csdn.net/woshilijiuyi/article/details/78959759

版权

Spring Cloud 专栏收录该内容

18 篇文章 0 订阅

订阅专栏

在spring cloud体系项目中，引入的重试机制保证了高可用的同时，也会带来一些其它的问题，如幂等操作或一些没必要的重试。今天就来分别分析一下 FeignClient 和 Ribbon 重试机制的实现原理和区别，主要分为三点：

1）FeignClient重试机制分析

2）Ribbon重试机制分析

3）FeignClient和Ribbon重试机制的区别于联系

1.FeignClient 重试机制分析

feign的重试机制默认是关闭的

源码如下

	//FeignClientsConfiguration.java
	@Bean
	@ConditionalOnMissingBean
	public Retryer feignRetryer() {
		return Retryer.NEVER_RETRY;
	}

当没有spring容器中不存在retryer这个实例的时候，会初始化这个bean， NEVER_RETRY

如何开启

	@Bean
    public Retryer feignRetryer() {
        return new Retryer.Default();
    }

在你的配置类中，添加如上代码，当然你也可以自定义Retryer。默认重试5次

FeignClient 重试机制的实现原理相对简单。首先看一下feignClient处理请求的拦截类：SynchronousMethodHandler,看一下该类中的代理方法invoke：

 @Override
  public Object invoke(Object[] argv) throws Throwable {
  //生成处理请求模板
    RequestTemplate template = buildTemplateFromArgs.create(argv);
    //获取重试配置类
    Retryer retryer = this.retryer.clone();
    while (true) {
      try {
        return executeAndDecode(template);
      } catch (RetryableException e) {
      //在异常里执行是否重试方法
        retryer.continueOrPropagate(e);
        if (logLevel != Logger.Level.NONE) {
          logger.logRetry(metadata.configKey(), logLevel);
        }
        continue;
      }
    }
  }

上面的默认重试配置Retryer,在其构造方法中，默认的请求次数为5次，如下：

 public Default() {
      this(100, SECONDS.toMillis(1), 5);
    }

判断是否重试的算法如下：

public void continueOrPropagate(RetryableException e) {
//重试次数大于最大请求次数，抛出异常
      if (attempt++ >= maxAttempts) {
        throw e;
      }

      long interval;
      if (e.retryAfter() != null) {
        interval = e.retryAfter().getTime() - currentTimeMillis();
        if (interval > maxPeriod) {
          interval = maxPeriod;
        }
        if (interval < 0) {
          return;
        }
      } else {
        interval = nextMaxInterval();
      }
      try {
        Thread.sleep(interval);
      } catch (InterruptedException ignored) {
        Thread.currentThread().interrupt();
      }
      sleptForMillis += interval;
    }

如果要关闭或者要重写 feignClient重试机制的话，可以自定义`feignRetryer`，在方法中不做重试，直接抛出异常。配置如下：

/**
 * @author zhangshukang
 */
@Configuration
public class FeignConfig {
    @Bean
    Retryer feignRetryer() {
        return new Retryer() {
            @Override
            //在这里重写 continueOrPropagate算法，可自定义处理方式。这里直接抛出异常，相当于不重试。
            public void continueOrPropagate(RetryableException e) {
                throw e;
            }
            @Override
            public Retryer clone() {
                return this;
            }
        };
    }
}

feign:
  hystrix:
    enabled: true
  client:
    config:
      # 全局配置
      default:
        connectTimeout: 5000
        readTimeout: 5000  
      # 实例配置，feignName即@feignclient中的value，也就是服务名
      feignName:
        connectTimeout: 5000
        readTimeout: 5000

feign时间的默认配置Request.Options 连接超时10s 读取超时60s，

，重试次数默认5次，包含第一次

如果同时配置了ribbon和feign的超时时间，系统发现options的配置不是默认配置，就会生成一个新的FeignOptions覆盖原有ribbon的配置，所以feign的配置优先级会更高，最后生效的是feign，贴部分源码：

IClientConfig getClientConfig(Request.Options options, String clientName) {
		IClientConfig requestConfig;
		if (options == DEFAULT_OPTIONS) {
			requestConfig = this.clientFactory.getClientConfig(clientName);
		}
		else {
			requestConfig = new FeignOptionsClientConfig(options);
		}
		return requestConfig;
	}

也就是说

feign和ribbon的超时时间只会有一个生效，规则:如果没有设置过feign超时，也就是等于默认值的时候，就会读取ribbon的配置，使用ribbon的超时时间和重试设置。否则使用feign自身的设置。

两者是二选一的，且feign优先。

2.Ribbon重试机制分析

默认配置：

ribbon的重试机制是默认重试一次。

属性	备注
ribbon.MaxAutoRetrues	重试相同的服务，默认次数为1
ribbon.MaxAutoRetruesNextServer	重试下一台服务，默认为1
ribbon.connectTimeout	连接超时时间2s
ribbon.readTimeout	读取数据超时5s
ribbon.okToRetryOnAllOperations	无论是超时还是connet异常，统统重试，默认为false，

Ribbon的默认配置类 DefaultClientConfigImpl 连接超时时间2s，读取超时时间5s

首先看一下我们ribbon常用的配置，已经配置用到的地方：

重试机制

#重试机制
#该参数用来开启重试机制，默认是关闭
spring.cloud.loadbalancer.retry.enabled=true
#对所有操作请求都进行重试
ribbon.OkToRetryOnAllOperations=true
#对当前实例的重试次数
ribbon.MaxAutoRetries=1
#切换实例的重试次数
ribbon.MaxAutoRetriesNextServer=1
#根据如上配置，当访问到故障请求的时候，它会再尝试访问一次当前实例（次数由MaxAutoRetries配置），
#如果不行，就换一个实例进行访问，如果还是不行，再换一次实例访问（更换次数由MaxAutoRetriesNextServer配置），
#如果依然不行，返回失败信息。

在这里插入图片描述

    这里从字面意思可以看出：
    retrySameServer：重试相同实例，对应MaxAutoRetries
    retryNextServer：重试下一实例，对应MaxAutoRetriesNextServer
    retryEnabled：重试所有操作，对应OkToRetryOnAllOperations

这里声明一点，关于feignClient如何整合ribbon负载均衡的，之前的博客已经有完整的分析：
《SpringCloud | Feign如何整合Ribbon进行负载均衡的？》，所以下面就跳过整合部分，直接分析负载均衡模块。

public T executeWithLoadBalancer(final S request, final IClientConfig requestConfig) throws ClientException {
        //获取重试机制配置:RequestSpecificRetryHandler,继续跟进该方法...
        RequestSpecificRetryHandler handler = getRequestSpecificRetryHandler(request, requestConfig);
        //这里很关键，很明显采用了命令模式，ribbon负载均衡的配置在这里传给LoadBalancerCommand类
        LoadBalancerCommand<T> command = LoadBalancerCommand.<T>builder()
                .withLoadBalancerContext(this)
                .withRetryHandler(handler)
                .withLoadBalancerURI(request.getUri())
                .build();

        try {
            return command.submit(
                new ServerOperation<T>() {
                    @Override
                    public Observable<T> 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);
            }
        }
        
    }

@Override
    public RequestSpecificRetryHandler getRequestSpecificRetryHandler(
            RibbonRequest request, IClientConfig requestConfig) {
            //这里如果配置了OkToRetryOnAllOperations为true，则所有的请求都进行重试。默认为false
        if (this.clientConfig.get(CommonClientConfigKey.OkToRetryOnAllOperations,
                false)) {
            return new RequestSpecificRetryHandler(true, true, this.getRetryHandler(),
                    requestConfig);
        }
        //如果没配置的话，如果不是get请求，就关闭重试
        if (!request.toRequest().method().equals("GET")) {
            return new RequestSpecificRetryHandler(true, false, this.getRetryHandler(),
                    requestConfig);
        }
        else {
        //如果是get请求，则开启重试。
            return new RequestSpecificRetryHandler(true, true, this.getRetryHandler(),
                    requestConfig);
        }
    }

上述代码是对请求类型进行区分，哪些重试，哪些不重试。
区别就在于第二个参数，来看一下第二个参数具体哪里用到了，继续跟进代码如下：

  public boolean isRetriableException(Throwable e, boolean sameServer) {
    //如果手动配置了所有请求都重试，或者get请求时，这里开启重试。
        if(this.okToRetryOnAllErrors) {
            return true;
        } else if(e instanceof ClientException) {
            ClientException ce = (ClientException)e;
            return ce.getErrorType() == ErrorType.SERVER_THROTTLED?!sameServer:false;
        } else {
            return this.okToRetryOnConnectErrors && this.isConnectionException(e);
        }
    }

刚刚上面提到了命令模式，属于RxJava的内容，事件驱动机制，有兴趣的可以自行研读。这里看一下上面命令模式执行类具体怎么用的：

public Observable<T> submit(final ServerOperation<T> 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();

    // 利用RxJava生成一个Observable用于后面的回调
    Observable<T> o =
            //选择具体的server进行调用
            (server == null ? selectServer() : Observable.just(server))
            .concatMap(new Func1<Server, Observable<T>>() {
                @Override
                // Called for each server being selected
                public Observable<T> call(Server server) {
                    context.setServer(server);
                    //获取这个server调用监控记录，用于各种统计和LoadBalanceRule的筛选server处理
                    final ServerStats stats = loadBalancerContext.getServerStats(server);

                    //获取本次server调用的回调入口，用于重试同一实例的重试回调
                    Observable<T> o = Observable
                            .just(server)
                            .concatMap(new Func1<Server, Observable<T>>() {
                                @Override
                                public Observable<T> 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();

                                ......省略部分代码

                                }
                            });
                    //设置针对同一实例的重试回调
                    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<Throwable, Observable<T>>() {
        @Override
        public Observable<T> 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);
        }
    });
}

上述代码典型的RxJava风格。

接下来是关键。o为Observable实例，类似于生产者，上面代码为Observable回调逻辑。上面有两行关键的代码：

o = o.retry(retryPolicy(maxRetrysSame, true));
o = o.retry(retryPolicy(maxRetrysNext, false));

首先看一下 retryPolicy 方法，这个就是 ribbon 重试算法的逻辑了，来看一下的实现：

 private Func2<Integer, Throwable, Boolean> retryPolicy(final int maxRetrys, final boolean same) {
        return new Func2<Integer, Throwable, Boolean>() {
            @Override
            public Boolean call(Integer tryCount, Throwable e) {
                if (e instanceof AbortExecutionException) {
                    return false;
                }
                //判断是否继续重试
                if (tryCount > maxRetrys) {
                    return false;
                }
                
                if (e.getCause() != null && e instanceof RuntimeException) {
                    e = e.getCause();
                }
                //进入异常处理
                return retryHandler.isRetriableException(e, same);
            }
        };
    }

上述代码是Ribbon判断是否重试的实现，根据我们配置的变量次数，进行判断，有异常则进入异常处理。
整体的重试机制就是将 LoadBalancerCommand 类中 retryPolicy 的重试实现逻辑，传入RxJava Observable对象的o.retry()方法，该方法接收的参数的就是一个Function：

public final Observable<T> retry(Func2<Integer, Throwable, Boolean> predicate) {
        return nest().lift(new OperatorRetryWithPredicate<T>(predicate));
    }

最后回过头看这两行代码，逻辑大致清晰许多，来看一下执行顺序：

o = o.retry(retryPolicy(maxRetrysSame, true));
o = o.retry(retryPolicy(maxRetrysNext, false));

执行顺序：
1）首先会先执行下面一行代码，获取负载均衡的重试配置，然后进行负载均衡，选取实例。
2）再执行上面一行代码，获取执行单个服务的重试配置，最后再执行具体的业务逻辑。

3.FeignClient 和 Ribbon重试区别与联系

feign:
  client:
    enabled: false
    config:
      default:
        #default为全局配置，如果要单独配置每个服务，改为服务名
        connectTimeout: 2000
        readTimeout: 2000

ribbon:
  MaxAutoRetries: 2
  MaxAutoRetriesNextServer: 2
  OkToRetryOnAllOperations: true
  ReadTimeout: 1000
  ConnectTimeout: 1000
spring:
  cloud:
    loadbalancer:
      retry:
        enabled: true

经测试如果都配置了fegin重试和ribbon重试，因为超时时间已fegin为准，ribbon不会重试，总重试次数是fegin的重试次数。

经过上面的分析，请求总次数 n 为feignClient和ribbon配置参数的笛卡尔积：
n(请求总次数)=feign(默认5次) * (MaxAutoRetries+1) * (MaxAutoRetriesNextServer+1)
注意：+1是代表ribbon本身默认的请求。

5=5*（0+1）*（0+1）

其实二者的重试机制相互独立，并无联系。但是因为用了feign肯定会用到ribbon，所以feign的重试机制相对来说比较鸡肋，自己feignClient的时候一般会关闭该功能。ribbon的重试机制默认配置为0，也就是默认是去除重试机制的，建议不要修改。如果配置不当，会因为幂等请求带来数据问题。所以建议关闭二者的重试功能。
如果开启的话，建议合理配置Hystrix的超时时间，在一些没必要的重试请求执行时，根据Hystrix的超时时间，快速失败，结束重试。

4. 当设置hystrix后

feign:
  client:
    config:
      default:
        #default为全局配置，如果要单独配置每个服务，改为服务名
        connectTimeout: 4000
        readTimeout: 2000
    #开启feign的hystrix支持,默认是false
    enabled: true

ribbon:
  MaxAutoRetries: 2
  MaxAutoRetriesNextServer: 2
  OkToRetryOnAllOperations: true
  ReadTimeout: 1000
  ConnectTimeout: 1000

spring:
  cloud:
    loadbalancer:
      retry:
        enabled: true

hystrix:
  command:
    default:
      execution:
        timeout:
          enabled: true
        isolation:
          thread:
            #全局设置超时
            timeoutInMilliseconds: 140000

当fegin超时后且hystrix没有没有达到最大超时，会继续重试，当最大重试次数超过fegin的最大重试次数但是还没到hystrix最大超时时间时也会停止。

测试：

fegin：2s ,hystrix:8s 最大重试次数4次

fegin：2s ,hystrix:14s 最大重试次数5次

以Ribbon的时间生效为例，Hystrix的超时时间需大于Ribbon重试总和时间，否则重试将失效，即： Hystrix超时时间 > （Ribbon超时时间总和）*重试次数

当OkToRetryOnAllOperations设置为false时，只会对get请求进行重试。如果设置为true，便会对所有的请求进行重试，如果是put或post等写操作，如果服务器接口没做幂等性，会产生不好的结果，所以OkToRetryOnAllOperations慎用。

如果不配置ribbon的重试次数，默认会重试一次
注意：默认情况下,GET方式请求无论是连接异常还是读取异常,都会进行重试非GET方式请求,只有连接异常时,才会进行重试

如果hystrix.command.default.execution.timeout.enabled为true,则会有两个执行方法超时的配置,一个就是ribbon的ReadTimeout,一个就是熔断器hystrix的timeoutInMilliseconds, 此时谁的值小谁生效
如果hystrix.command.default.execution.timeout.enabled为false,则熔断器不进行超时熔断,而是根据ribbon的ReadTimeout抛出的异常而熔断,也就是取决于ribbon
ribbon的ConnectTimeout,配置的是请求服务的超时时间,除非服务找不到,或者网络原因,这个时间才会生效
ribbon还有MaxAutoRetries对当前实例的重试次数,MaxAutoRetriesNextServer对切换实例的重试次数, 如果ribbon的ReadTimeout超时,或者ConnectTimeout连接超时,会进行重试操作
由于ribbon的重试机制,通常熔断的超时时间需要配置的比ReadTimeout长,ReadTimeout比ConnectTimeout长,否则还未重试,就熔断了
为了确保重试机制的正常运作,理论上（以实际情况为准）建议hystrix的超时时间为:(1 + MaxAutoRetries + MaxAutoRetriesNextServer) * ReadTimeout

5.如何设置Hystrix线程池大小

Hystrix线程池大小默认为10

hystrix:
    threadpool:
        default:
            coreSize: 10

每秒请求数 = 1/响应时长(单位s) * 线程数 = 线程数 / 响应时长(单位s)

也就是

线程数 = 每秒请求数 * 响应时长(单位s) + (缓冲线程数)

标准一点的公式就是QPS * 99% cost + redundancy count

比如一台服务, 平均每秒大概收到20个请求,每个请求平均响应时长估计在500ms,
线程数 = 20 * 500 / 1000 = 10
为了应对峰值高并发,加上缓冲线程,比如这里为了好计算设为5,就是 10 + 5 = 15个线程
b. 如何设置超时时间

还拿上面的例子,比如已经配置了总线程是15个,每秒大概20个请求,那么极限情况,每个线程都饱和工作,也就是每个线程一秒内处理的请求为 20 / 15 = ≈ 1.3个 , 那每个请求的最大能接受的时间就是 1000 / 1.3 ≈ 769ms ,往下取小值700ms.
实际情况中,超时时间一般设为比99.5%平均时间略高即可,然后再根据这个时间推算线程池大小
————————————————
版权声明：本文为CSDN博主「zzzgd816」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/zzzgd_666/article/details/83314833
原文链接：https://blog.csdn.net/zzzgd_666/article/details/83314833