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

先点赞再看，养成好习惯

前言

在网络请求中，因为网络是不可靠的，因此常常会有请求失败的场景。针对这种问题，一般的作法是增长重试机制，在请求失败后从新请求，尽可能保证请求的成功，从而提升服务的稳定性。

重试的风险

但是大多数人不肯意轻易的重试，由于每每重试会带来更大的风险。好比过多的重试，会给被调用服务形成更大的压力，放大原有的问题。

以下图所示，服务 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 还有一些语义上的约定：

GET	POST	PUT	DELET
列出URI，以及该资源组中每一个资源的详细信息（后者可选）。	在本组资源中建立/追加一个新的资源。该操做每每返回新资源的URL。	使用给定的一组资源替换当前整组资源。	删除整组资源。
安全（更是幂等）	非幂等	幂等	幂等

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

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