您现在的位置是：首页 > 知识问答网站首页知识问答

retry 直译就是重试，核心意思是在一次操作失败之后，按照预设规则自动重新发起这次操作，常见于编程接口调用网络请求任务执行等场景，它的作用就是应对临时故障，比如网络波动服务器短暂超时请求偶发报错，不用人工手动重新执行，由程序自动再次尝试，提升任务最终成功的概率，是开发里非常基础常用的容错方案。之所以要引入 retry，是因为很多错误并不是永久性故障，永久故障比如参数错误权限不足就算重试一百次也不会成功，而临时故障比如网络抖动接口瞬时繁忙数据库短暂锁等待，等待一小段时间再重试大概率就能成功，如果没有 retry，一次临时失败就会直接判定任务失败，会造成不必要的业务中断，所以 retry 本质是针对瞬时异常做的容错补偿手段。

retry 基础工作流程

1 发起第一次请求或者任务执行

2 判断本次执行结果，区分错误类型

3 如果属于可重试错误，等待设定的间隔时间

4 再次发起请求，也就是执行一次 retry

5 重复上面判断等待重试的循环，直到执行成功，或者达到最大重试次数上限

6 达到上限仍然失败，就抛出最终失败，交给上层业务做兜底处理

核心关键参数

参数名称	说明
最大重试次数	一共允许重试多少次，注意有的定义是总尝试次数，有的是首次失败之后额外重试次数，写代码时要区分清楚
重试间隔	每两次重试之间等待多久，常见固定间隔，也有指数退避间隔
可重试异常白名单	只有指定类型报错才触发 retry，避免对永久错误盲目重试
超时时间	单次请求本身的超时，和重试间隔是两个独立概念

两种主流重试策略

固定间隔 retry，每次重试等待相同时长，实现最简单，缺点是如果服务器本身压力很大，大量请求同时固定间隔重试，容易形成重试风暴，继续压垮服务。

指数退避 retry，也就是 exponential backoff，每次等待时间成倍增加，比如第一次等 1 秒第二次 2 秒第三次 4 秒，还经常加上随机抖动，打散重试请求，是生产环境更推荐的方案。

使用 retry 的重要注意点

第一，不是所有报错都适合 retry，像参数非法鉴权失败资源不存在这类永久性错误，绝对不要重试，否则会白白消耗资源。

第二，要保证操作幂等，这个是最重要的前提，如果接口不是幂等的，重试有可能造成重复扣款重复下单这类严重业务事故，幂等就是同一个请求执行多次，最终效果和执行一次完全一样。

第三，必须设置最大重试上限，不能无限重试，否则程序会一直卡在重试循环里。

第四，做好日志记录，每一次 retry 都要记录重试次数报错信息时间，方便后续排查问题。

第五，外部场景也会见到 retry 这个单词，比如软件下载页面游戏加载页面的 retry 按钮，含义就是点击之后重新加载重新尝试本次操作。

总结一下，retry 就是重试，是针对临时性失败自动再次执行操作的容错手段，开发使用的时候一定要搭配合理策略，确认接口幂等，筛选可重试异常，设置上限，防止盲目重试带来新风险。

【常见问题】

问题 1 retry 和 timeout 有什么区别

回答 1 retry 是失败之后再次尝试操作，timeout 是单次操作等待的最大时限，单次请求等待超过 timeout 就判定本次失败，之后才有可能触发 retry，二者经常搭配使用，但含义完全不同。

问题 2 retry 为什么一定要做幂等处理

回答 1 retry 会重复发起同一个请求，如果业务不具备幂等性，重复执行就会产生重复业务结果，比如重复提交订单重复扣款，所以使用 retry 之前必须确认接口是幂等的。

问题 3 指数退避 retry 相比普通 retry 有什么优势

回答 1 普通 retry 一般是固定等待间隔，指数退避 retry 等待时间逐步倍增，还可以增加随机抖动，能够降低大量客户端同时重试带来的重试风暴，保护后端服务，是生产环境优选的 retry 方案。

【免责申明】

本文内容仅为技术概念科普讲解，不构成任何项目开发方案推荐，实际业务落地使用 retry 时，请结合自身业务场景评估风险，自行完成测试验证。