两个参数管不同的事
超时决定单次操作等待多久后放弃，重试决定放弃之后是否再来一次。它们的组合直接决定系统的行为：超时太短会把慢但正常的操作判为失败，重试又叠加重复执行；重试没有退避会在对方已经过载时继续加压；非幂等操作被重试则可能产生重复资源或重复副作用。合理做法是先按正常耗时分布确定超时阈值，再按幂等性与失败类型决定是否重试。
基本信息
| 超时 | 单次执行的等待上限 |
|---|---|
| 重试 | 失败后的再执行次数与间隔 |
| 退避 | 重试间隔随次数递增，避免集中冲击 |
| 前提 | 只有幂等操作才适合自动重试 |
设计要点
- 按分布定超时：以正常耗时的较高分位数为基准，留出合理余量。
- 区分失败类型：网络超时、依赖不可用可重试；参数错误与权限不足不应重试。
- 退避递增：采用指数退避并加入随机抖动，避免多个任务同时重试。
- 限制总时长：设置总超时，避免重试让任务无限延长并占用变更窗口。
- 非幂等不重试：创建资源、发送通知、提交工单类操作失败后交由人工判断。
- 记录重试次数：把重试次数写入执行记录，重试频繁本身就是故障信号。
失败类型与处置
| 失败表现 | 是否重试 | 处置 |
|---|---|---|
| 连接超时 | 可重试 | 退避后重试有限次数 |
| 依赖服务不可用 | 可重试 | 等待依赖恢复，同时告警 |
| 权限不足 | 不重试 | 立即失败并通知修正权限 |
| 参数或语法错误 | 不重试 | 修正资产后重新执行 |
| 资源已存在冲突 | 不重试 | 改为幂等判断或人工确认 |
| 业务校验不通过 | 不重试 | 回退并保留现场 |
超时设置不当本身就会制造故障：把慢操作判为失败并触发重试，会让同一份变更在目标系统上执行两次，留下难以清理的重复状态。
重试次数频繁上升通常意味着真实故障在恶化，而不是任务需要更多重试。把重试次数纳入监控，比调大重试上限更有价值。