如何在调用接口时进行优雅重试

在日常的编码过程中，无论是和本地服务相关的本机资源交互，还是和本地服务相关的

远程资源甚至是远程服务进行交付，都可能会遇到失败（异常），这时候，我们最常见

的做法就是重试。

 

什么是正确的重试

和任何的锲而不舍都需要向着现实低头一样，“重试”也需要有终止条件（即有条件的重试），

想象一样买彩票的场景，如果屡次不中，一直尝试不停歇，那不是得破产吗？

第一种，固定循环次数方式

伪代码

缺点：

不带 backoff 的重试，对于下游来说会在失败发生时进一步遇到更多

的请求压力，继而进一步恶化

 

第二种 带固定时间重试

伪代码

 

缺点：

虽然这次带了固定间隔的 backoff，但是每次重试的间隔固定，此时

对于下游资源的冲击将会变成间歇性的脉冲；特别是当集群都遇到类似的问题时，步调一致

的脉冲，将会最终对资源造成很大的冲击，并陷入失败的循环中

 

第三种：随机delay的方式

 

缺点：

如果依赖的底层服务持续地失败，改方法依然会进行固定次数的尝试，并不能起到很好

的保护作用。



对结果是否符合预期，是否需要进行重试依赖于异常。



无法针对异常进行精细化的控制，如只针部分异常进行重试

 

 

以上就是这三种重试方式

 

推荐使用 

resilience4j-retr y 或则

spring-retry 等库来进行组合