先点赞再看，养成好习惯
前言
在网络请求中，由于网络是不可靠的，所以经常会有请求失败的场景。针对这种问题，通常的做法是增加重试机制，在请求失败后重新请求，尽量保证请求的成功，从而提高服务的稳定性。
重试的风险
可是大多数人不愿意轻易的重试，因为往往重试会带来更大的风险。比如过多的重试，会给被调用服务造成更大的压力，放大原有的问题。
如下图所示，服务 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没有报错就算成功了？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的重试策略：
- 判断重试次数是否已经超过最大次数（默认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 库。
而且还提有 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 总比问题扩大更好。
参考
原创不易，禁止未授权的转载。如果我的文章对您有帮助，就请点赞/收藏/关注鼓励支持一下吧❤❤❤❤❤❤
java
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用。你还可以使用@来通知其他用户。