1 重试策略概述
重试策略（Retry Strategy）是提升系统可靠性的自动化机制：当对外请求因暂时性故障而失败时，在满足一定约束的前提下再次发起操作。其目标是在故障持续时间较短、可恢复的前提下，尽量把失败转化为成功，并避免额外放大负载。
在自动化与分布式系统中，重试往往不是“失败就重来”这么简单，而是与超时、熔断、降级、幂等性、退避算法、抖动、最大重试次数以及重试可行性判断等配套协同设计。若缺少这些约束，重试可能把短暂故障演变为系统性压力。
1.1 为什么需要重试
分布式系统中存在大量瞬时波动：网络抖动、瞬间拥塞、短暂限流、临时服务不可用、线程或连接池暂时耗尽等。对这类“可恢复失败”，一次失败并不必然意味着最终无法完成请求。重试利用时间间隔给系统“自愈”的机会，同时提高整体成功率与用户体验。
此外，重试还能在一定程度上抵消上游偶发的不稳定行为，例如网关侧偶发超时、下游短暂排队等。通过合理的重试规则，可将随机故障的影响从“直接失败”转移为“延迟增加但最终成功”。
1.2 适用场景与不适用场景
适用场景通常具备以下特征：
不适用或需要谨慎的场景包括：
- 确定性失败：例如参数错误、权限校验失败、业务规则拒绝等通常不应重试。
- 不可控副作用：例如非幂等的写入且无法去重，或会触发不可逆的外部动作。
- 故障已进入“不可恢复”阶段：例如依赖方长期不可用、配置错误导致的稳定失败。
1.3 与可靠性工程的关系
从可靠性工程角度，重试属于“容错与恢复”手段的一部分。其设计与目标通常与以下方面相关：
- 可用性提升：把暂时故障的影响转化为可恢复的延迟。
- 故障隔离：通过与熔断、降级配合，避免局部故障扩散。
- 资源控制：通过重试预算、最大重试次数和退避，约束额外负载。
- 正确性保障：通过幂等性、去重键与一致性/补偿机制，避免重复写入或重复消费。
2 重试触发条件
重试触发条件决定了“何时重试、是否值得重试”。没有明确规则的重试容易把不可恢复错误重复消耗资源，甚至放大故障。
2.1 错误类型与可重试性判断
可重试性判断通常基于错误的性质，而非仅凭失败次数。例如：
- 网络类问题：连接超时、读写超时、连接重置、DNS短暂异常等常被视为可尝试。
- 服务端过载/拥塞：短暂限流、队列拥堵、暂时不可用可视为可重试信号（但需配合退避与预算）。
- 资源竞争：例如连接池暂时耗尽、线程池排队过长，可能在短时间后缓解。
不可重试的常见类别包括：参数校验错误、权限不足、业务校验失败、结构性配置问题等。
2.2 状态码与异常分类
在 HTTP 场景中，重试往往会结合状态码类别与语义：
- 常见可重试：涉及超时、网关超时、临时不可用、限流等（通常要求退避与熔断联动）。
- 常见不可重试：客户端错误中与请求本身有关的类型（如参数不合法）通常不应重试。
在更通用的场景中，会把异常分为：超时、连接错误、服务端返回错误、协议错误、业务异常等，并给出映射到“可重试/不可重试/需降级”的决策表。该表需要结合业务与系统边界持续维护。
2.3 幂等性相关约束
重试的关键约束之一是幂等性：当同一请求重复执行多次，系统结果应保持一致或能被有效治理。对于幂等操作，可以更积极地重试；对于非幂等操作，则需要依赖去重键、事务一致性或补偿机制，避免重复产生副作用。
若无法保证幂等，重试应默认收敛为“最多一次尝试”或引导到其他补救路径。
2.4 客户端/服务端协同信号
可靠的重试还需要客户端与服务端协同。例如：
- 服务端响应头/错误码中的可重试指示：告知客户端是否建议重试。
- 限流与速率信息：让客户端依据返回的节流参数调整重试时机。
- 服务端的降级信号：当系统处于保护模式时，客户端应避免继续加压。
协同信号的目标是让“重试判断”从经验猜测变为可计算的策略输入。
3 重试参数建模
重试参数建模用于把策略落到可执行的数值约束，避免“无限重试”或“重试过密导致雪崩”。
3.1 最大重试次数
最大重试次数是硬约束，限制重试次数上限。它的设置通常取决于：
- 允许的延迟上界（与用户体验、SLA相关）
- 失败恢复的典型时间尺度（例如是否主要是短暂拥塞）
- 操作的副作用风险（幂等性越强，可尝试更高次数）
- 系统容量与并发规模（越易造成压力，越需要保守）
在建模中，最大次数往往与重试预算共同使用，形成“次数-时间”的双重上限。
3.2 总超时时间与预算（Retry Budget）
Retry Budget（重试预算）用于限制重试期间的总耗时与尝试成本。常见做法包括：
- 为一次用户请求设置总时间上限（从首发到最终返回）。
- 在预算内分配每次尝试的超时与等待间隔。
- 当预算耗尽立即停止重试，转入失败处理（如降级或返回错误）。
预算的价值在于避免在故障长尾阶段持续消耗线程、连接或队列资源。
3.3 每次重试的超时设置
每次重试本身也需要超时，以免单次尝试无限挂起。每次超时的设置应与：
相匹配。通常建议把单次超时控制得足够短，确保失败能尽快进入下一次尝试或触发策略分支。
3.4 重试范围：仅读/可写/全链路
重试范围用于界定“到底重试哪些环节”。例如在微服务链路中，重试可以限定为：
分层重试的目的是把重试的影响面收敛到可控范围。
4 退避与时间控制
退避与时间控制决定了重试发生的间隔。目标是在尽量提高成功率的同时，避免形成“并发洪峰”。
4.1 固定间隔重试
固定间隔重试在每次失败后等待同样的时长再尝试。它实现简单，但容易出现同步问题：大量客户端在相同失败点开始重试，可能在同一时间再次冲击服务端。
因此固定间隔通常需要配合额外机制，例如加入抖动，或控制客户端群的重试相位。
4.2 线性退避
线性退避把等待时间按步长线性增加，例如每次失败增加固定毫秒数或按比例递增。相较固定间隔，它能缓和后续重试的频率，降低拥塞持续时的冲击。
在恢复时间不确定但整体偏短的场景中，线性退避常被用作折中方案。
4.3 指数退避
指数退避让等待时间随尝试次数呈指数增长，能够显著减少长时间故障下的请求放大。典型形式为：等待时间与 \(2^n\) 成比例，通常还会设置最大等待上限，防止间隔过长导致体验崩坏。
指数退避与熔断配合时，能更有效避免在故障持续期间引入持续压力。
4.4 自适应退避与速率整形
自适应退避会根据观测到的系统状态动态调整等待时间，例如：
- 根据历史成功率与延迟分布调整退避系数。
- 根据服务端返回的节流信息（如限流提示）调整间隔。
- 在观察到队列排队加剧时延长等待。
速率整形则更偏向控制整体发送节奏，例如令牌桶、漏桶或基于排队长度的调度，以使重试与正常流量更平滑地共享资源。
4.5 抖动（Jitter）设计
抖动（jitter）是对等待时间加入随机扰动，目的是打散客户端重试的同步性。常见做法包括：
- 在固定/线性/指数退避结果上叠加随机偏移。
- 使用区间随机：例如在 0 到基础退避值之间取随机。
- 对不同重试轮次使用不同抖动幅度。
抖动通常被认为是降低重试风暴风险的基础工程手段。
5 重试顺序与策略组合
仅有“何时重试”还不够，系统往往需要定义“按什么顺序重试、失败后做什么切换”，以获得更高的成功率与更好的隔离效果。
5.1 分级策略：快速重试与慢速重试
分级策略把重试过程拆分为多个阶段：初期快速重试以应对短暂抖动；在多次失败后进入慢速重试以降低压力。实现上可通过调整退避参数、增加等待上限或降低重试频率完成。
这种策略能在短故障时快速恢复，同时对持续异常保持克制。
5.2 失败后切换备用通道（如多区域/多实例）
当主通道失败时，系统可以切换备用实例、备用区域或备用路由。此类切换通常需要：
- 健康检查与探测机制。
- 选择策略（随机、最少连接、权重等）。
- 与缓存、DNS或服务发现协同。
切换的前提是备用通道具备可用性且切换不会引入新的链路错误成本。
5.3 与批处理、队列重投递的关系
在批处理或消息队列场景中，“重试”常表现为“重投递”。需要额外考虑：
- 消息的重复投递与去重（幂等消费者）。
- 递延重投递的延迟策略（常与指数退避类似）。
- 队列积压与消费者吞吐的耦合。
重投递并不等同于同步重试：它通过异步化把压力从请求线程转移到队列调度，但仍需要预算与节奏控制。
5.4 结合熔断器的“重试+断路”方案
熔断器（Circuit Breaker）用于在失败率升高或错误持续时快速阻断后续尝试。与重试结合时，通常形成：
- 熔断器判断当前依赖是否“值得试”。
- 若允许再试，重试策略负责“怎么试”（退避、预算、次数）。
- 若熔断处于打开或半开状态，直接失败或转入降级。
这种组合能避免在依赖已经处于保护状态时继续用重试制造更多失败。
6 幂等性与副作用治理
幂等性与副作用治理回答一个核心问题：重试不是免费午餐，如何保证重复执行不改变最终业务效果，或至少能被纠正。
6.1 幂等写入的常见做法
常见做法包括：
- 幂等更新：使用“覆盖式”更新或基于版本号/条件更新。
- 唯一约束：通过唯一索引或约束防止重复创建。
- 乐观并发控制：借助版本字段或条件写入实现幂等效果。
- 状态机化：把操作建模为可比较的状态转移，避免重复触发不可逆步骤。
选择方式取决于数据模型与业务语义。
6.2 去重键（Idempotency Key）
去重键（Idempotency Key）是在一次业务操作中生成的标识。客户端在重试时携带同一个键，服务端据此识别重复请求并返回一致结果或已有处理结果引用。
去重键通常需要：
- 生成策略（如基于请求上下文的唯一标识）
- 存储与过期策略（避免无限增长）
- 与返回结果绑定（确保重复请求拿到同样的语义结果）
6.3 事务一致性与补偿机制
当无法直接实现强幂等时，系统可以采用补偿机制。典型思路包括：
- 采用“先记录、再执行、再确认”的一致性模式。
- 把跨服务操作拆分为可补偿步骤，并对失败执行撤销或对账。
- 使用事务外模式（例如事务消息、事件驱动与补偿）实现最终一致。
重试与补偿需要协同：重试应尽量减少失败后的重复行动，而补偿用于兜底纠正错误结果。
6.4 重试导致的重复消费问题
重复消费常见于支付、扣减库存、发券、通知触达等场景。治理要点包括：
- 以幂等消费者或幂等处理器保证同一业务意图只生效一次。
- 使用去重键或消费序号。
- 对外部副作用（短信、邮件、Webhook）建立“已发送/已接收”记录，避免多次触发。
在实践中，很多“重试事故”并非来自重试本身，而是来自副作用治理缺失或粒度不一致。
7 系统组件与落地方式
重试策略通常在不同层次实现：客户端库、网关、服务内部框架以及工作流平台。不同层的职责边界不同，组合时需要避免重复重试或形成叠加放大。
7.1 客户端库中的重试中间件
客户端库中间件适合统一封装重试逻辑，便于在多业务线复用。它通常负责：
- 将网络/协议错误映射为可重试性
- 应用退避、抖动与重试预算
- 在可控范围内重试与降级
- 透传幂等键或重试上下文
客户端层的优势是控制粒度细、无需修改服务端；挑战是需要统一策略并防止各业务自行改造导致不一致。
7.2 API 网关与网关侧重试
网关侧重试适合在入口处对“可恢复故障”做统一处理，例如后端超时或短暂异常。网关层通常更能观察整体流量，但也可能因多租户与路由复杂而难以判断具体业务副作用。
因此网关侧重试通常会更保守，并强调与下游幂等机制协同。
7.3 服务内部重试框架
服务内部框架用于处理服务到服务之间的依赖调用。其优势在于能够根据业务上下文进行更精确的幂等与补偿控制，例如按步骤重试或仅重试某个读取分支。
同时服务内部更容易访问领域数据，从而做可重试性判断的增强。
7.4 工作流/自动化平台中的重试节点
在工作流引擎或自动化平台中，重试常以“节点失败重试”形式出现。由于工作流本身有状态，平台可以提供：
- 重试次数与时间窗
- 失败处理分支与补偿路径
- 幂等与去重的业务上下文存储
该方式适合复杂编排，但也要防止“编排层重试”与“调用层重试”叠加产生多次放大。
8 与其他机制的协同
重试与其他可靠性机制的协同决定了系统整体行为。孤立地设计重试，往往会忽略错误传播与资源约束。
8.1 超时（Timeout）联动
超时与重试必须联动建模。若单次超时过长，重试会把线程与连接占满；若超时过短，可能把正常慢请求误判为失败从而触发不必要重试。
通常会以“预算”为上层约束，按预算分配每次超时，并确保退避等待不会侵占整体响应时延过多。
8.2 熔断（Circuit Breaker）联动
熔断器提供“是否值得继续尝试”的全局开关。重试策略应尊重熔断状态：
- 熔断打开：避免继续发起尝试。
- 半开：按小流量探测恢复情况，再决定是否恢复重试。
- 熔断闭合：允许按退避规则重试。
这种联动可显著降低错误扩散与无效重试。
8.3 降级（Degradation）与回退（Fallback）
降级与回退用于在依赖不稳定时提供替代响应或降低功能可用性。例如：
- 使用缓存结果或返回可接受的默认值。
- 将复杂操作简化为可执行的轻量路径。
- 延后非关键步骤，并让用户先完成主流程。
重试与回退可并行：若重试耗尽预算仍失败，则触发回退路径，避免长时间阻塞。
8.4 限流（Rate Limiting）联动
限流与重试存在天然张力：限流在限制请求，重试会增加请求。联动设计通常要求：
- 对限流错误使用退避与抖动，降低重试频率。
- 根据限流返回的节流信息调整等待。
- 在系统繁忙时减少重试，而不是“继续加压试图突破”。
8.5 观察性联动：日志、指标与追踪
为了评估重试效果并定位问题，需要把重试行为纳入观察性：
- 记录每次尝试的结果、错误类型与耗时。
- 统计重试次数分布、成功率与最终延迟。
- 通过追踪系统标注重试链路，识别链路上重复执行的位置。
同时要避免日志过量，可用采样或分级记录策略。
9 风险与反模式
重试虽然能提升成功率，但也可能引发连锁反应。理解风险与反模式是正确使用的前提。
9.1 重试风暴（Retry Storm）
重试风暴指大量客户端在相同故障期间同时重试，造成请求峰值持续上升，进一步拉高错误率。常见诱因包括固定间隔重试、缺少抖动、无限制并发重试和缺少熔断隔离。
降低重试风暴的关键在于：退避、抖动、熔断与预算，以及明确可重试性判断。
9.2 雪崩效应与级联失败
当下游服务因重试额外负载而继续变慢，导致更多超时和失败，从而触发更大规模重试，最终形成级联衰退。该过程常在高并发与故障持续时出现。
解决思路通常涉及：限制重试产生的额外请求量、缩短失败探测周期并使用熔断快速切断。
9.3 对不可重试错误盲目重试
盲目重试会把本应快速失败的错误拖入冗余等待。对于参数错误、权限缺失、稳定配置问题等，重试只是重复浪费资源，还可能触发更多异常链路。
正确做法是建立可重试性映射，并在策略中显式排除不可重试错误。
9.4 忽略幂等性造成的数据污染
当重试覆盖了非幂等写入而缺乏去重治理，可能导致重复创建、重复扣减或重复触发外部通知。即便最终响应失败，副作用可能已经发生，造成“失败但数据已变”。
治理依赖幂等写入、去重键以及一致性/补偿机制。
9.5 “越重试越慢”的性能陷阱
在某些系统中，重试会显著增加排队与拥塞，导致整体延迟变长并降低成功率。表现为：重试次数增加后，成功率提升不明显，但尾延迟变差。
这类问题通常需要通过预算、熔断阈值以及自适应退避进行校准，而不是一味提高重试次数。
10 观测、评估与调优
重试策略需要持续迭代。调优的核心是把“看起来合理”变成“数据驱动的有效”。
10.1 指标体系：成功率、重试次数、延迟分布
常用指标包括：
- 最终成功率与失败率
- 平均与分位延迟（如P95、P99）
- 重试次数分布（0次、1次、2次…）
- 单次尝试耗时分布与等待时间分布
- 可重试错误与不可重试错误占比
通过这些指标可以判断重试是否在提高成功率的同时付出了过高的延迟成本。
10.2 追踪与因果定位
追踪系统可帮助识别重试发生在哪一跳，以及是否造成下游排队或错误飙升。通过对比“重试前后”的错误码、耗时与资源指标，可以定位问题是退避策略不合适、幂等键缺失，还是熔断阈值设置不合理。
10.3 端到端成功成本评估
重试的成本不仅是请求时间，还包括：
- 额外的网络与计算资源
- 线程/连接占用与排队增加
- 下游依赖的压力
- 业务副作用治理带来的复杂度
端到端成功成本评估要求综合延迟与资源消耗，判断“多重试是否值得”。
10.4 参数调优方法（仿真/回放/灰度）
常见调优方式：
- 仿真：在受控环境模拟故障分布，测试不同退避和预算参数。
- 回放：基于历史请求重放，观察策略对延迟与成功率的影响。
- 灰度发布：小流量验证策略稳定性，监控关键指标并逐步扩大。
调优过程应与熔断、限流和降级策略一起考虑，避免单点优化导致系统整体行为失衡。
11 实例与伪代码（概念级）
以下示例以概念层面描述流程，强调策略编排逻辑而非具体语言实现。
11.1 基于指数退避的通用流程
概念流程通常包括：
- 判断请求是否可重试（基于错误类型、状态码、上下文约束）。
- 若不可重试，直接返回或进入降级路径。
- 若可重试且未超过最大次数与预算，则等待退避时间后再尝试。
- 退避时间采用指数增长，并设置最大上限。
- 当预算耗尽，停止重试并返回最终失败。
该流程的关键是预算与可重试判断要先于重试执行。
11.2 含抖动的重试调度示例
含抖动的调度通常在基础退避计算完成后叠加随机扰动：
- 基础等待时间由指数或线性公式给出；
- 在一个扰动区间内生成随机偏移；
- 最终等待时间=基础等待+偏移，并再次受最大等待上限约束。
该设计用于打散并发客户端的重试时刻。
11.3 与幂等键的配套示例
配套示例通常遵循：
- 客户端为业务意图生成幂等键，并在首次请求中携带。
- 重试时沿用同一幂等键，避免服务端把重复尝试当作新意图。
- 服务端根据幂等键返回相同结果或引用已有处理记录。
- 若幂等键过期或不存在，则需要回退到更严格的校验或补偿流程。
这样可把“重试带来的重复执行风险”转化为“可治理的重复识别问题”。
11.4 配合熔断器的示例流程
与熔断器配合时，一般逻辑为：
- 调用前询问熔断器状态：允许、半开试探或拒绝。
- 若拒绝，直接失败或执行回退。
- 若允许，则执行重试策略，但所有尝试都在熔断器允许的范围内。
- 每次失败或成功会更新熔断器的统计窗口。
- 若错误率达到阈值，熔断器打开，后续请求不再重试。
该过程确保重试不会在依赖明显不可用时继续消耗资源。
12 文化梗与常见口头禅
工程团队常用一些“带梗”的表达来提醒重试的边界。它们更像经验守则，而非操作规则。
12.1 “先试三次，再说人生”的工程玩笑（不建议照做）
“先试三次”常被当作调侃：表达“给系统多一次尝试”的直觉。但如果不考虑可重试性、预算、幂等与退避，这种口头禅很容易变成盲目重试的代名词。更可靠的做法是以错误类型与约束为依据，而不是固定次数。
12.2 避免“重试当万能药”的自嘲提醒
重试并不能修复确定性错误，也无法替代正确的限流、熔断、扩容或修复根因。团队常用自嘲来提醒：重试只是“在条件满足时的补救”，不是“把故障延迟成成功”的魔法。
12.3 工程里真正重要的：可重试性与资源约束
最终的共同认识是：重试是否值得取决于可重试性判断与副作用治理，同时必须遵守资源预算与时间边界。只有当策略能在失败场景下保持克制，重试才会从“看似努力”变成“真正可靠”。