前言
在网络请求中，由于网络是不可靠的，所以经常会有请求失败的场景。针对这种问题，通常的做法是增加重试机制，在请求失败后重新请求，尽量保证请求的成功，从而提高服务的稳定性。
重试的风险
可是大多数人不愿意轻易的重试，因为往往重试会带来更大的风险。比如过多的重试，会给被调用服务造成更大的压力，放大原有的问题。
如下图所示，服务 A 调用 服务 B，服务 B 根据请求数据不同，会调用 服务 C 和 服务 D。此时服务 C 出现故障，不可用了，那么服务 B 中所有对服务 C 的请求都会超时，但服务 D 现在还是可用的；可由于服务 A 中大量的重试导致服务 B 的负载快速升高，很快的将服务 B 的负载打满（比如连接池沾满）。现在调用服务 D 的分支请求也不可用了，因为服务 B 已经被重试请求打满，无法再处理任何请求了。 
既然重试有风险，那难道就不应该重试吗？失败就直接失败，啥都不管吗？
不同时机下的失败重试
是否进行重试，这个需要区分当前失败的原因，不能简单粗暴的决定重试或者不重试。网络很复杂，链路很长，不同类型的协议，决定是否重试的策略也有所不同。
HTTP 协议下的重试
一个基本的 HTTP 请求，会包含以下几个阶段：
- DNS 解析
- TCP 三次握手
- 发送&接受对端数据
在 DNS 解析阶段时，如果域名不存在，或者域名没有 DNS 记录，根据域名无法解析到对应的主机地址列表，那么根本就无法发起请求，此时重试没有任何意义，所以并不需要重试
在 TCP 握手阶段，如果目标服务不可用，那么此时重试也没有什么意义，因为在请求的第一步- 握手都不成功，大概率这个 host 是不可用的。
挺过了 DNS 和握手两个阶段之后，终于到了收发数据的阶段。到了这一步一旦出现失败，是否重试要考虑的因素可就更多了。
如下图所示的这种情况中，因为网络拥塞等原因，导致数据到达服务端时间过长，但最终服务端也收到了完整的报文，已经开始处理请求，可此时客户端因为超时放弃了该请求，那么如果客户端此时新建一条 TCP 连接发起重试，那么对于服务端来说就会收到两次相同的请求报文，处理两次该请求，可能造成严重的后果
所以这种已经发送成功的情况，就不适合重试 
并没有那么简单，应用层的 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 中，重试的策略又会有一些变化： 
如果在 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的重试策略：
- 判断重试次数是否已经超过最大次数（默认3次），超过就不重试
- 判断哪些异常不需要重试
- UnknownHostException - 找不到主机
- ConnectException - TCP 握手失败
- SSLException - SSL 握手失败
- InterruptedIOException(ConnectTimeoutException/SocketTimeoutException) - 握手超时，Socket读取超时（也可以粗略的认为是响应超时）
- 判断是否是幂等请求，幂等请求才可以重试
- 判断请求报文是否已经完成发送，若未完成发送才可以重试
- 重试时直接重新请求，没有间隔
这样看起来，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 中的重试策略：
- 默认重试次数为3（包括第一次请求），配置大于1时才会触发重试
- 默认是 Failover 策略，所以重试不会重试当前节点，只会重试（可用节点 -> 负载均衡 ->路由之后的）下一个节点
- TCP 握手超时会触发重试
- 响应超时会触发重试
- 报文错误或其他错误导致无法找到对应的 request，也会导致 Future 超时，超时就会重试
- 对于服务端返回的 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 库。 
那 Feign 中的重试策略是怎么样的呢？这个问题实在不好回答，因为要区分很多情况，在不同的 Feign Client 下，重试策略都有所不同
首先，Feign 是有内置的重试策略的，如下图所示，Feign 的重试在调用 HttpClient 之外，而且每次重试之前有一定间隔。
默认配置下，最大重试5次（包括第一次），每次重试前会间隔一定时间（sleep），而且这个每次间隔时间是随着重试次数的增加而递增的，重试间隔计算公式为：
重试间隔=重试间隔（默认100ms）∗1.5当前重试次数−1重试间隔 = 重试间隔（默认100ms） * 1.5 ^ {当前重试次数 -1}重试间隔=重试间隔（默认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 的配置
总结
重试虽然看着很简单，但如果想安全稳定的重试，要考虑的因素还是很多的。一定要结合当前业务场景，上下文信息去综合考虑是否应该重试和每次重试的次数；而不是一拍脑袋就定一个重试机制，暴力重试往往只会放大问题，带来更严重的后果。
京公网安备 11010502036488号