1. 背景
1.1 问题的背景
类似组件和服务瞬间断开网络连接、服务暂时不可用，或者当服务繁忙时出现超时等这些临时性故障，这些临时性故障通常可以自己修复（延迟合适时间重新触发请求，该请求可能成功）
1.2 常见的错误处理方案
1.2.1 终止操作，返回错误信息，记录错误日志
如果错误表明故障不是暂时性的或者重新执行也不可能成功的。如密码错误等操作问题
1.2.2 重试
立即重试：
错误不常见或极少见，则可能是由不常见的情况（例如网络包在传输过程中损坏）导致的，这种情况下可以立即再次重试，因为不大可能会重复出现同一个故障并且请求可能会成功延迟后重试
错误由普遍的连接或繁忙故障引起的，则网络或服务可能需要很短的一段时间来等待连接问题得以修复或积压的工作得以清除。可以等待合适的时间，然后重试请求
1.3 重试的问题和注意事项
-
调整重试策略来匹配业务要求和故障性质
-
对于某些非关键操作，最好是快速失败而不是重试多次并影响系统的吞吐量
交互式web系统，最好在重试次数较少时失败，并在重试尝试之间只用短暂延迟，并向用户显示合适的消息
对于批处理应用，增加重试次数并且在尝试之间采用指数级增长的延迟时间可能更为合适
对于运行状况已经接近或处于其容量上限的繁忙服务， 不要重试
-
考虑操作是否幂等
对于某个请求在进行大量的重试后失败，则最好停止继续请求并立即报告失败，当限制期限过期后，可以试探性的允许一个或多个请求通过以查看它们是否成功。
2. 重试相关的策略
2.1 比较重要的三个参数：重试次数、调用间隔、总延时
-
重试次数：
- 如果对重试次数不加限制，在出现下游系统故障，或者恰好命中下游系统bug的情况下，可能出现在相当一段时间内的重试都会以失败告终，这时候的重试不仅没有起到提升对外服务质量的效果，反而会对当前服务和下游服务都造成非常大的不必要负荷
调用间隔：两次调用之间的调用间隔时长，主要体现在退避策略中
总延时：整体的请求耗时（包括首次请求以及后续的重试请求的整体耗时）
2.2 常见的重试策略
默认最多重试3次
默认在1秒内失败都会重试
增加熔断机制，如果不在熔断状态，则允许重试
组合多个重试策略
从不重试
总是重试
...
2.3 退避策略（backoff）
无退避策略：立即重试
线性退避：每次等待固定时间后重试
随机退避：在一定范围内等待一个随机时间后重试
指数退避：连续重试时，每次等待都是前一次的倍数
综合退避：如线性退避+随机抖动 或者 指数退避+随机抖动
...
2.4 兜底恢复策略（recover）
- 所有重试耗尽都没有成功后的兜底恢复逻辑
2.5 Google的SRE给出的一些实践建议
针对每个失败请求，设置重试次数的上限，比如最多重试3次。
针对整个客户端的调用，设置最大的重试与请求的比例。即重试请求最大不会超过某个时间窗口内的请求数的10%，即写放大指数最大就是110%。
客户端记录一段时间内的重试次数，判断在最近的时间窗口内，如果出现了大量的服务都需要重试的情况，可以判断当前服务端处于过载状态，服务端也可以通过状态码直接返回“拒绝重试”的状态，而这个状态会被带到请求链路中抛到上层，避免更高层服务调用的重试。
2.6 backup requests策略：主要用于解决长尾请求
客户端可以根据过去一个时间窗口内的请求时长的pct999，判断大多数正常请求的耗时分布，当请求耗时已经达到这个阈值（在各个场景下，这个值都小于超时阈值），不必等请求返回而直接重试，这种策略叫做backup requests。在超时出现比较多的场景下，这种提早重试策略能够提升服务的响应速度，所带来的代价就是可能出现的一些额外请求
3. 重试的场景
3.1 Http、Https协议下的重试--HttpClient
一个基本的 HTTP 请求，会包含以下几个阶段：
DNS 解析：如果出现无法解析到对应的主机地址列表的错误，则无需重试
TCP 三次握手：如果出现目标服务不可用，则大概率这个host是不可用的，也无需重试
发送&接受对端数据
-
在HttpClient的重试实现中以下几种情况是不会重试的：
如果请求被成功发送过，就不再重试了
-
发生以下四种异常不重试：
InterruptedIOException（ConnectTimeoutException/SocketTimeoutException）握手超时，Socket读取超时
UnknownHostException（找不到主机）
ConnectException（TCP握手失败）
-
SSLException（SSL握手失败）
TCP建立连接后，会先进行SSL的握手，验证对端证书，生成临时对称密钥之类的操作。
如果在SSL握手阶段就发生失败，比如证书到期，证书不受信等问题，那么也是完全不需要重试的。因为这种问题不会是短暂的，一旦出现就是长时间失败，重试也是失败。
3.2 RPC框架的重试--Dubbo的重试机制（v2.6.x）
默认重试次数为3（包括第一次请求），配置大于1时才会触发重试
默认是 Failover 策略，所以重试不会重试当前节点，只会重试（可用节点 -> 负载均衡 ->路由之后的）下一个节点
TCP 握手超时会触发重试
响应超时会触发重试
报文错误或其他错误导致无法找到对应的 request，也会导致 Future 超时，超时就会重试
对于服务端返回的 Exception（比如provider抛出的），属于调用成功，不会进行重试
3.3 MQ消息--RocketMQ的重试机制
3.3.1 消息发送阶段
RocketMQ有同步发送、异步发送、oneway发送方式
同步发送：发消息的时候会同步阻塞等待broker返回的结果，如果没成功，则不会收到SendResult，这种是最可靠的
有重试机制，默认三次，如果超时或者失败则会自动重试，下面是设置重试次数的API用法
producer.setRetryTimesWhenSendFailed(10);
3.3.2 消费消息阶段
手动提交+自动重试（次数有限制），重试次数用完了怎么办，会进入死信队列
4. 重试的风险与预防** 重试存在放大故障的风险，那如何防止放大故障的风险
4.1 限制单点重试与正常请求的比例
针对整个客户端的调用，设置最大的重试与请求的比例。即重试请求最大不会超过某个时间窗口内的请求数的10%，即写放大指数最大就是110%。-----来源Google SRE的建议
we implement a per-client retry budget. Each client keeps track of the ratio of requests that correspond to retries. A request will only be retried as long as this ratio is below 10%. The rationale is that if only a small subset of tasks are overloaded, there will be relatively little need to retry.https://sre.google/sre-book/handling-overload/
4.2 限制链路重试
4.2.1 在微服务中对于重试的实践中，具体在哪层操作重试？
-
有的是在最外层请求包装重试
优点在于直接对最外层服务负责，请求方法指数最方便控制
缺点在于单次重试开销较大；
举例：A -> B -> C -> D ，C->D失败了，导致从A再来一遍
-
有的是在各个服务请求处就近重试
优点在于请求重试开销较小，有利于提升各个服务的服务质量指标
缺点在于可能出现多层嵌套重试的情况，如果重试次数限制有问题的话，容易出现请求放大的问题。
举例：A -> B -> C -> D ，C->D失败了，C重试了3次依然失败，导致B -> C失败，然后B开始重试，指数级增长
-
特殊的重试错误码方案：
-
特殊的重试错误码往上传递：上游对下游的重试请求不重试
通过特殊错误码（调用失败，但别重试）来返回给调用上层以此来达到让上层不要进行重试的作用，但对业务代码有侵入改造
这种方式理想情况下只有最下一层发生重试，它的上游收到错误码后都不会重试。
-
特殊的重试错误码往下传递：下游对上游的重试请求不进行重试
往上传递重试错误码只能确保上游接收到错误码不会进行重试，但如果收不到错误码怎么办
举例：A -> B -> C , 而 B -> C 出现失败重试，而此时如果A -> B出现超时，而此时A还没有拿到B返回的错误码， 那么A依然会继续重试，那么怎么办？
-
4.3 超时时间配置问题
如果A->B重试成功了，但此时已经超时了怎么办，这不等于白重试了吗 ---- 问题出在超时时间配置的不合理
4.3.1 backup requests方案
backup requests方案的思想就是提前重试，用访问量来换成功率(或者说低延时)的思想，这样机制能大大减少整体延时，这个机制也必须同样遵循重试与正常请求的比例
4.3.2 基于trace推荐超时时间配置
基于对链路的监控，结合上下游情况来计算推荐的超时时间配置
5. 重试组件
Spring Retry组件
guava-retrying组件
Hystrix的hystrix-go组件
.......
6. 重试相关的常见故障
-
重试导致的常见故障
大量重试或无限重试导致下游被打挂
由于未做幂等性或幂等性失效导致的重复数据
-
重试策略配置存在问题，比如立即重试导致并发问题
未做重试或限制次数（但未做兜底方案）导致的错误或事故
