头图

请求失败,应该重试吗?不应该吗?

空无
English
先点赞再看,养成好习惯

前言

在网络请求中,由于网络是不可靠的,所以经常会有请求失败的场景。针对这种问题,通常的做法是增加重试机制,在请求失败后重新请求,尽量保证请求的成功,从而提高服务的稳定性。

重试的风险

可是大多数人不愿意轻易的重试,因为往往重试会带来更大的风险。比如过多的重试,会给被调用服务造成更大的压力,放大原有的问题。

如下图所示,服务 A 调用 服务 B,服务 B 根据请求数据不同,会调用 服务 C 和 服务 D。此时服务 C 出现故障,不可用了,那么服务 B 中所有对服务 C 的请求都会超时,但服务 D 现在还是可用的;可由于服务 A 中大量的重试导致服务 B 的负载快速升高,很快的将服务 B 的负载打满(比如连接池沾满)。现在调用服务 D 的分支请求也不可用了,因为服务 B 已经被重试请求打满,无法再处理任何请求了。

image.png

如果服务自身是可用的,但网络出现较大的延迟、抖动或者丢包,导致请求到达目标服务或返回发起服务超时;此时如果客户端发起重试,那么对于接收端来说,很可能会收到多个相同的请求。所以服务端还需要增加幂等的处理,保证多次请求下结果一致

image.png

既然重试有风险,那难道就不应该重试吗?失败就直接失败,啥都不管吗?

不同时机下的失败重试

是否进行重试,这个需要区分当前失败的原因,不能简单粗暴的决定重试或者不重试。网络很复杂,链路很长,不同类型的协议,决定是否重试的策略也有所不同。

HTTP 协议下的重试

一个基本的 HTTP 请求,会包含以下几个阶段:

  1. DNS 解析
  2. TCP 三次握手
  3. 发送&接受对端数据

在 DNS 解析阶段时,如果域名不存在,或者域名没有 DNS 记录,根据域名无法解析到对应的主机地址列表,那么根本就无法发起请求,此时重试没有任何意义,所以并不需要重试

在 TCP 握手阶段,如果目标服务不可用,那么此时重试也没有什么意义,因为在请求的第一步- 握手都不成功,大概率这个 host 是不可用的。

挺过了 DNS 和握手两个阶段之后,终于到了收发数据的阶段。到了这一步一旦出现失败,是否重试要考虑的因素可就更多了。

如下图所示的这种情况中,因为网络拥塞等原因,导致数据到达服务端时间过长,但最终服务端也收到了完整的报文,已经开始处理请求,可此时客户端因为超时放弃了该请求,那么如果客户端此时新建一条 TCP 连接发起重试,那么对于服务端来说就会收到两次相同的请求报文,处理两次该请求,可能造成严重的后果

所以这种已经发送成功的情况,就不适合重试

image.png

问题来了,怎么样才能知道我发送成功了呢?socket.write没有报错就算成功了?SocketChannel.write之后,Buffer 写空了就算成功了?

并没有那么简单,应用层的 socket write,只是将数据写入 SND Buffer 中,至于 SND Buffer 中的数据什么时候被操作系统发送至网络,这个并没有任何保证。阻塞和非阻塞也只是针对 socket.write 这个操作的,当 SND Buffer已满,无法将数据写入内核 SND Buffer 时,就会发生阻塞。

但我们可以粗略的认为,socket.write 成功 并且 应用层 buffer 被写空,就是已经发送成功了。

现在看看另一种情况,当数据发送时对端就直接关闭了socket,返回 rst 标识:

image.png

那么这种情况,就很适合进行重试。因为对于服务端来说,并没有开始处理这个请求,所以重试(重建连接重发请求)只会提高可用性,并不会造成什么负担


HTTP 协议中,对 Request Method 还有一些语义上的约定

GETPOSTPUTDELET
列出URI,以及该资源组中每个资源的详细信息(后者可选)。在本组资源中创建/追加一个新的资源。该操作往往返回新资源的URL。使用给定的一组资源替换当前整组资源。删除整组资源。
安全(更是幂等)非幂等幂等幂等

PUT/DELETE 是幂等操作,所以就算处理相同报文的请求也不会有数据重复之类的问题。但 POST 可不是,POST 的语义是创建/添加,这是一个非幂等的请求类型。

现在回到上面重试的问题,如果请求报文已经发送成功,但响应超时,但由请求的 API Method 是一个DELETE 类型,这种情况就可以考虑重试,因为 DELETE 语义上是幂等的;GET/PUT 同理,语义上幂等的就可以考虑重试。

但 POST 可不行,因为语义上是非幂等的,重试很可能造成重复的处理请求

可是……一切真的那么美好吗?能严格准守语义的 API 能有几家?所以单靠语义上的约定,非常不稳妥,一定要足够了解服务端的接口是否支持幂等,才可以考虑重试问题。

HTTPS 下的重试

HTTPS 面世这么多年,终于在近几年完全普及了,没升级的网站在浏览器中都会提示不安全,目前能暴露在公网的 Web API 也基本都是上 HTTPS 的。

在 HTTPS 中,重试的策略又会有一些变化:

image.png

上图是HTTPS 握手的流程,在 TCP 建立连接之后,会先进行 SSL 的握手,验证对端证书,生成临时对称密钥之列的操作。

如果在 SSL 握手阶段就发生失败,比如证书到期,证书不受信等问题,那么也是完全不需要重试的。因为这种问题不会是短暂的,一旦出现就是长时间失败,重试也是失败。

主流网络库 & RPC 框架中的重试机制

介绍完了 HTTP(S) 协议下对重试的考虑,现在来看看主流网络库对重试的处理方式,看看这种主流开源项目中的处理机制够不够“合理”

Apache HttpClient 的重试机制(v4.x)

Apache HttpClient 是 Java 里最主流的一个 HTTP 工具库了(后端方向),虽然 JDK 也提供了基本的 HTTP SDK,但……太基础了,没法直接使用。而 Apache HttpClient(简称Apache HC)弥补了这个不足,提供了一套超级强大的 HTTP SDK,功能强大、使用简单、所有组件都可以定制。

Apache HC 默认的重试策略类在org.apache.http.impl.client.DefaultHttpRequestRetryHandler,先来看看实现(省略了一些不重要的代码):

//返回true,代表需要重试,false不重试
@Override
public boolean retryRequest(
    final IOException exception,
    final int executionCount,
    final HttpContext context) {
    
    //判断重试次数是否达到上线
    if (executionCount > this.retryCount) {
        // Do not retry if over max retry count
        return false;
    }
    //判断哪些异常不用重试
    if (this.nonRetriableClasses.contains(exception.getClass())) {
        return false;
    } 
    //判断是否是幂等请求
    if (handleAsIdempotent(request)) {
        // Retry if the request is considered idempotent
        return true;
    }
    //请求报文是否已经发送
    if (!clientContext.isRequestSent() || this.requestSentRetryEnabled) {
        // Retry if the request has not been sent fully or
        // if it's OK to retry methods that have been sent
        return true;
    }
    // otherwise do not retry
    return false;
}

简单总结下 Apache HC的重试策略:

  1. 判断重试次数是否已经超过最大次数(默认3次),超过就不重试
  2. 判断哪些异常不需要重试

    1. UnknownHostException - 找不到主机
    2. ConnectException - TCP 握手失败
    3. SSLException - SSL 握手失败
    4. InterruptedIOException(ConnectTimeoutException/SocketTimeoutException) - 握手超时,Socket读取超时(也可以粗略的认为是响应超时)
  3. 判断是否是幂等请求,幂等请求才可以重试
  4. 判断请求报文是否已经完成发送,若未完成发送才可以重试
  5. 重试时直接重新请求,没有间隔

这样看起来,Apache HC 中默认的重试策略,和我们上一节介绍的“合理的”重试策略完全一致。由此可见这种主流的开源项目真的很优秀,质量非常高,所有设计都按照标准来,拿这种项目的源码当学习资料更能事半功倍。

Dubbo 的重试机制(v2.6.x)

Dubbo 中重试机制的代码在com.alibaba.dubbo.rpc.cluster.support.FailoverClusterInvoker(2.7以后包名更新为 org.apache.dubbo)

public Result doInvoke(Invocation invocation, final List<Invoker<T>> invokers, LoadBalance loadbalance) throws RpcException {
    //获取配置的重试次数,默认1即不重试
    int len = getUrl().getMethodParameter(invocation.getMethodName(), Constants.RETRIES_KEY, Constants.DEFAULT_RETRIES) + 1;
    Set<String> providers = new HashSet<String>(len);
    for (int i = 0; i < len; i++) {
        Invoker<T> invoker = select(loadbalance, invocation, copyinvokers, invoked);
        invoked.add(invoker);
        RpcContext.getContext().setInvokers((List) invoked);
        try {
            Result result = invoker.invoke(invocation);
            if (le != null && logger.isWarnEnabled()) {
                logger.warn("Although retry the method " + invocation.getMethodName()
                            + " in the service " + getInterface().getName()
                            + " was successful by the provider " + invoker.getUrl().getAddress()
                            + ", but there have been failed providers " + providers
                            + " (" + providers.size() + "/" + copyinvokers.size()
                            + ") from the registry " + directory.getUrl().getAddress()
                            + " on the consumer " + NetUtils.getLocalHost()
                            + " using the dubbo version " + Version.getVersion() + ". Last error is: "
                            + le.getMessage(), le);
            }
            return result;
        } catch (RpcException e) {
            //Biz类型的异常,会抛出异常,不进行不重试,非Biz类的RpcException都会进行重试
            if (e.isBiz()) { // biz exception.
                throw e;
            }
            le = e;
        } catch (Throwable e) {
            le = new RpcException(e.getMessage(), e);
        } finally {
            providers.add(invoker.getUrl().getAddress());
        }
    }
}

从代码中可以看出,只有不是 Biz 类型的 RpcException,才会触发重试。继续分析代码看看什么场景会触发重试……算了不贴代码了,直接上答案!

简单总结一下 Dubbo 中的重试策略:

  1. 默认重试次数为3(包括第一次请求),配置大于1时才会触发重试
  2. 默认是 Failover 策略,所以重试不会重试当前节点,只会重试(可用节点 -> 负载均衡 ->路由之后的)下一个节点
  3. TCP 握手超时会触发重试
  4. 响应超时会触发重试
  5. 报文错误或其他错误导致无法找到对应的 request,也会导致 Future 超时,超时就会重试
  6. 对于服务端返回的 Exception(比如provider抛出的),属于调用成功,不会进行重试

Dubbo 的重试策略还是有一些激进的,并没有像 Apache HC 那样谨慎……所以在使用 Dubbo 时,重试策略一定要小心,避免重试到一些不支持幂等的服务。如果你的 provider 不支持幂等,最好将重试次数配置为 0

Feign 的重试机制(v11.1)

Feign 是一个使用简单 Java 的 Http 客户端,也是 Spring Cloud 中推荐的 RPC 框架。虽然 Feign 也属于 Http 客户端,但它和 Apache HC 之类的库相比却有很大的不同。

下面 Feign 的核心结构图,从图上可以看到,Feign 的客户端部分,除了支持 JDK 内置的 Http Client 以外,还支持 Apache HC,Google Http,OK Http 等 Http 库。

image.png

而且还提有 encoders/decoder 的抽象……这么看起来,它并不能算是一款基础的 Http 客户端,更应该称为 “Http 工具”?或者叫一个 RPC 的基础抽象?

那 Feign 中的重试策略是怎么样的呢?这个问题实在不好回答,因为要区分很多情况,在不同的 Feign Client 下,重试策略都有所不同

首先,Feign 是有内置的重试策略的,如下图所示,Feign 的重试在调用 HttpClient 之外,而且每次重试之前有一定间隔。

image.png

默认配置下,最大重试5次(包括第一次),每次重试前会间隔一定时间(sleep),而且这个每次间隔时间是随着重试次数的增加而递增的,重试间隔计算公式为:

$$重试间隔 = 重试间隔(默认100ms) * 1.5 ^ {当前重试次数 -1}$$

如下图所示,重试的次数越大,每次的重试间隔就会越长

image.png

但这是在调用 HttpClient 之外的重试,如果只是使用 Feign 内置默认 JDK HTTP Client 的话也不会出什么问题,因为JDK HTTP Client 很简单,没有重试机制,单靠 Feign 的重试机制就足够了。

可是在配合三方 Http Client (比如 Apache HC)时,情况就不太一样了,因为三方的 Http Client 内部往往是有重试机制的。

如果三方的 HttpClient 有重试,Feign 又有重试,那么相当于重试了两层,重试次数变成了 N * N

比如在 Apache HC 下,按照前面的介绍,默认重试3次,而 Feign 默认重试5次,那么最坏的情况下,重试次数高达 15 次。

image.png

而且这还只是 Feign 在基本用法下的重试机制,如果在 Spring Cloud 下,配合 Ribbon 之类的负载均衡器,情况会更复杂一些,本文就不过多介绍了,有兴趣的看看 Spring Cloud 下 Feign 的配置

总结

重试虽然看着很简单,但如果想安全稳定的重试,要考虑的因素还是很多的。一定要结合当前业务场景,上下文信息去综合考虑是否应该重试和每次重试的次数;而不是一拍脑袋就定一个重试机制,暴力重试往往只会放大问题,带来更严重的后果。

如果不确定是否可以安全的重试,那么就不要重试,禁用这些框架的重试,Failfast 总比问题扩大更好。

参考

原创不易,禁止未授权的转载。如果我的文章对您有帮助,就请点赞/收藏/关注鼓励支持一下吧❤❤❤❤❤❤
阅读 1.2k

坚持原创,专注分享 JAVA、网络、IO、JVM、GC 等技术干货

2.6k 声望
3.5k 粉丝
0 条评论
你知道吗?

坚持原创,专注分享 JAVA、网络、IO、JVM、GC 等技术干货

2.6k 声望
3.5k 粉丝
宣传栏