请求失败，应该重试吗？不应该吗？

先点赞再看，养成好习惯

前言

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

重试的风险

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

如下图所示，服务 A 调用 服务 B，服务 B 根据请求数据不同，会调用 服务 C 和 服务 D。此时服务 C 出现故障，不可用了，那么服务 B 中所有对服务 C 的请求都会超时，但服务 D 现在还是可用的；可由于服务 A 中大量的重试导致服务 B 的负载快速升高，很快的将服务 B 的负载打满（比如连接池沾满）。现在调用服务 D 的分支请求也不可用了，因为服务 B 已经被重试请求打满，无法再处理任何请求了。 如果服务自身是可用的，但网络出现较大的延迟、抖动或者丢包，导致请求到达目标服务或返回发起服务超时；此时如果客户端发起重试，那么对于接收端来说，很可能会收到多个相同的请求。所以服务端还需要增加幂等的处理，保证多次请求下结果一致

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

不同时机下的失败重试

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

HTTP 协议下的重试

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

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

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

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

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

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

所以这种已经发送成功的情况，就不适合重试 问题来了，怎么样才能知道我发送成功了呢？socket.write没有报错就算成功了？SocketChannel.write之后，Buffer 写空了就算成功了？

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

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

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

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

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

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

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

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

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

HTTPS 下的重试

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

在 HTTPS 中，重试的策略又会有一些变化： 上图是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 库。 而且还提有 encoders/decoder 的抽象……这么看起来，它并不能算是一款基础的 Http 客户端，更应该称为 “Http 工具”？或者叫一个 RPC 的基础抽象？

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

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

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

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

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

但这是在调用 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 次。

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

总结

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

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

参考

• 如何优雅地重试-InfoQ
• Apache Dubbo – Github
• Feign – Github
• Apache HttpClient – Github

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