本文内容是目前团队内小磊同学对重试机制实现方案的梳理总结。

从为什么需要重试的背景开始，到重试的场景，大致的一些设计思路，最后通过两个成熟的retry组件进行案例讲解，理论+实战。

背景

重试是系统提高容错能力的一种手段。在一次请求中，往往需要经过多个服务之间的调用，由于网络波动或者其他原因，请求可能无法正常到达服务端或者服务端的请求无法正常的返回，从而导致请求失败，这种失败往往可以通过重试的方式来解决。因此服务之间的重试机制提高了整个系统的故障恢复能力。

重试场景

典型的重试场景如下：

1. 网络抖动问题造成的请求失败，通过重试提高成功率。

2. 由于系统负载高原因导致请求变慢，导致请求超时，通过重试提高成功率。

3. 由于系统故障或服务不可用导致请求没能成功，通过重试保证数据落地。

那么是不是所有请求都可以重试？
显然不是，重试依赖于接口的幂等性，假设一个接口多次使用相同参数调用会导致其违反数据约束，那么得到的结果可能会在我们预期之外。对于幂等不了解的伙伴，可以参看：高并发下接口幂等性解决方案

设计思路

如何设计一个优雅的重试机制？优雅的重试机制应该具备如下几点特点：

• 无侵入：或者侵入低，这个好理解，不改动当前的业务逻辑，对于需要重试的地方，可以很简单的实现

• 可配置：包括重试次数，重试的间隔时间，是否使用异步方式等

• 通用性：最好是无改动（或者很小改动）的支持绝大部分的场景，拿过来直接可用

模板方式

将重试机制的实现抽取成一个模板，预留接口。示例如下：