1. 为什么需要重试机制——从一次线上故障说起那天下午我的手机被运维瞬间打爆原因是线上订单服务大面积超时连带支付回调也攒了整整五千多条。事后翻日志才发现罪魁祸首是下游的库存服务在做一次全量缓存重建偶尔返回 503而我们的调用方代码里没有任何重试保护一次失败就直接把异常抛给了上层最终导致整条链路雪崩。事后复盘时组里的老大哥悠悠来了一句“这个场景要是用上 Spring 的 Retryable 就稳了。”那是我第一次真正正视 Spring 框架里的重试注解。所谓重试说白了就是当一次方法调用因为偶发的网络抖动、下游限流或瞬时故障而失败时系统自动按照预设的次数和间隔策略重新发起调用直到成功或达到最大尝试次数为止。它解决的根本矛盾是分布式环境下异常往往是“大概率事件”你的代码必须假设上下游随时可能不给面子。对于 Spring 生态的开发者来说Retryable 与 Recover 这对组合就是专门干这个的——前者标记“哪个方法需要重试”后者定义“重试彻底失败后怎么兜底”。我还记得第一次看到这对注解时的感受网上的帖子不是贴个 demo 就完事就是参数解释得云里雾里真到了自己要接入时踩了一堆莫名其妙的坑。所以这篇就按我的实操路径来写从原理讲到配置从踩坑讲到排查争取让你看完就能直接落地到项目里。这篇文章适合谁看如果你在用 Spring Boot 搭服务、写接口或者你的任务里恰好有“调用三方接口要稳定”这种需求那这篇文章就是给你准备的。哪怕你目前还没遇到过重试场景把这些知识点提前存着也能让你以后处理故障时多一张底牌。带杠精属性的朋友可能会说“重试我自己用 for 循环写不行吗”行当然行但当你需要处理退避策略、异常类型区分、回退兜底这些细节时自己手写才知道维护成本有多高。接下来我们会从设计思路上聊聊为什么选择注解方案再手把手把核心参数和恢复方法讲透最后补充高频故障的排查经验。2. 核心参数逐个拆Retryable 的选择逻辑与 Recover 的兜底边界2.1 Retryable 注解参数不是全写上就完事先看 Retryable 最基础的写法。在 Spring Boot 工程里第一步需要引入 spring-retry 依赖然后在启动类或配置类上加上 EnableRetry 开关之后才能在目标方法上使用注解。很多新手会漏了 EnableRetry结果注解写了半天完全没生效这是最经典的入门坑。配上参数之后大概是这个样子Service public class PaymentService { private static final Logger log LoggerFactory.getLogger(PaymentService.class); Retryable( retryFor {RemoteAccessException.class, TimeoutException.class}, noRetryFor {IllegalArgumentException.class}, maxAttempts 4, backoff Backoff(delay 1000, multiplier 2, maxDelay 10000) ) public String callPaymentGateway(String orderId) { // 模拟调用三方支付接口 return restTemplate.postForObject(/pay, orderId, String.class); } }这里面的参数各有各的门道。retryFor 指定哪些异常会触发重试Spring 4.3 之后推荐用它替代已废弃的 include它的底层逻辑是判断抛出的异常是否为指定异常类型或其子类。noRetryFor 则是黑名单像参数校验异常这种“重试一万次也不可能成功”的业务异常一定要塞进去不然系统会做着无意义的等待。maxAttempts 是整个重试过程最多执行多少次方法调用含第一次原始调用写 4 意味着最多打四次。最后一个 backoff 是退避策略delay 是第一轮失败后的等待毫秒数multiplier 代表每一轮延迟时间的翻倍系数maxDelay 则限制单次最大延迟防止指数爆炸。如果说参数是“规定动作”那配置这些参数背后的逻辑才是真正的“自选动作”。选哪些异常重试、选哪些不重试本质上是在回答一个问题当前场景里什么失败原因值得我多花时间等下去网络抖动、下游超时这类是值得等等的因为恢复了就没事了可业务校验不通过、数据格式错误这类你再怎么试结果都一样唯一的结局就是白白占着线程资源。我在实际项目里通常会把“可重试异常”控制在比较窄的范围内优先考虑 Spring 自带的 RemoteAccessException再根据下游具体实现补充各自的超时异常类型。做这个约定之前一定要和团队对齐光靠个人经验很容易出现“A 觉得可以重试、B 觉得不能重试”的拉扯。另一个容易被忽略的点是Retryable 默认是同步阻塞的。它对当前线程进行 sleep 式的等待并不是异步任务。如果你在一个高并发接口里对每个请求都配置了多次重试线程池可能在高峰期被打满进而引发响应延迟。所以参数不是越大越好maxAttempts 和 backoff 的组合需要结合下游的恢复时间和自身接口允许的耗时上限来综合评估。比如我遇到过一兄弟把 maxAttempts 配了 10 次、delay 配了 5 秒结果单次请求最长要等 40 多秒前端早超时放弃了后端线程却被死死占住最后靠扩大线程池才勉强缓解这就属于没有结合实际场景拍脑袋配参数。2.2 Recover 注解的场景边界与匹配机制Recover 看起来只是一个普通的兜底注解但它内部有一套严谨的匹配规则。简单说当 Retryable 方法经过指定次数的尝试后仍然失败Spring Retry 会把最后一次抛出的异常交回容器容器在同一个类里扫描被 Recover 标记的方法按参数类型匹配找到能处理当前异常的那个恢复方法执行它并返回结果。这个兜底方法最关键的限制是参数列表的第一个参数必须是被捕获的异常类型剩余参数则要和原方法的参数列表保持一致。见下面这个示例Recover public String recoverCallPaymentGateway(RemoteAccessException e, String orderId) { log.error(支付网关重试耗尽订单号{}异常{}, orderId, e.getMessage()); // 可以做降级、告警、落库等操作 return fallback; }这里有两个常见的误解。第一个误解是“只要写了 Recover 它就会自动执行”实际上如果可重试异常被 noRetryFor 排除掉了Retryable 会在第一次失败后立即抛出异常根本不会走到 Recover 这一步。第二个误解是“多个 Retryable 方法可以共用一个恢复方法”从代码层面不是绝对不行前提是异常类型与参数列表恰好能匹配上但这样会让恢复逻辑的上下文变得很模糊我个人的建议是每个方法配一个语义清晰的恢复方法宁可多写几个也别偷懒写成一个万能恢复方法不然日志里分辨兜底来源都得看半天。要知道 Recover 的“兜底”到底写在哪个位置还得理解 Spring Retry 的拦截器调用链路。Retryable 方法被调用时Spring 通过 AOP 拦截器创建了一次 RetryTemplate 的执行过程重试判断由 RetryPolicy 和 BackOffPolicy 共同决定一旦 RetryPolicy 判定“不再继续”异常会被抛给拦截器拦截器再去容器里寻找 Recover 方法。理解这个执行链路以后很多令人困惑的行为就说得通了为什么 Recover 能在注解方法内部没有 catch 的情况下接住异常因为异常根本没在原方法里被消化而是沿 AOP 链路向上传递给了恢复处理器。我刚开始用这套机制时犯过一个错把恢复方法写在另一个类里还特地用 Service 注入进来。结果 Spring 容器里扫描不到这个恢复方法重试耗尽后异常直接抛给了调用方我盯着日志查了半天没明白错误出在哪。后来翻官方文档才注意到恢复方法必须和被重试方法定义在同一个类中且该类需要被 Spring 管理。原理上其实也好理解Recover 的解析依赖方法签名所在的上下文跨类配置会让代理对象无法建立准确的映射。相比之下如果你希望恢复逻辑更解耦可以考虑直接使用 RetryTemplate 自行调用或者利用默认的 Recover 规则在同一个类内组合职责相近的多个重试方法。3. 工程落地实操Spring Boot 中从依赖引入到业务封装的完整步骤3.1 环境准备与依赖引入细节如果你用的是 Spring Boot 2.x 或 3.x引入 spring-retry 依赖并不复杂关键在于版本选择。Spring Boot 的 BOM 已经帮我们管理好了 spring-retry 的版本所以在 pom.xml 里直接写即可dependency groupIdorg.springframework.retry/groupId artifactIdspring-retry/artifactId /dependency启动类或配置类上加上 EnableRetry 注解然后项目里所有用了 Retryable 的 Bean 都会被自动代理。有一点值得提醒Spring Boot 2.x 默认不引入 AOP 相关依赖而 Retryable 的底层实现强依赖 Spring AOP所以建议同时引入 spring-boot-starter-aopdependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-aop/artifactId /dependency从 Spring Boot 2.6 左右的版本开始如果少了这个 starter运行时会报出无法找到 Advisor 相关类的异常。我个人通常会在依赖里同时看到 spring-retry 和 aop 两个身影才放心。对于只想快速尝试注解效果的新人也别忘了 Spring Boot 的自动配置只负责扫描 Bean并不会自动开启重试功能这也就是为什么第一步必须是 EnableRetry。一个让很多同学困惑的问题是为什么我引入了依赖、加了 EnableRetry但调用还是不会重试这时请你先确认自己是不是在同一个类里“自调用”——也就是内部方法之间互相调用。比如 PaymentService 的 createOrder 方法里 this.callPaymentGateway(...) 这种写法AOP 代理根本不会生效。因为 Spring AOP 的代理对象只能拦截外部对它的调用类内部 this 调用直接走的是原始对象拦截器无从插入。解决方式无非两种要么把被重试的方法抽到另一个 Spring Bean 里再注入调用要么用 AopContext.currentProxy() 获取当前代理对象进行调用。我更推荐前者代码更清晰也更容易被同事看懂。3.2 实操准备先从一个库存扣减的模拟场景开始为了更接近真实场景我设计了一个微服务里非常常见的业务调用库存服务扣减库存。这个接口偶尔会因数据库锁等待或网络超时而失败所以我们希望它在遇到小幅波动时能自己恢复同时在重试耗尽后能走一条降级路线把失败信息记录下来。先定义一个实体和接口抽象public class InventoryResult { private boolean success; private int remainStock; private String message; // 构造器、getter/setter 省略 }然后定义库存服务客户端类Component public class InventoryClient { private static final Logger log LoggerFactory.getLogger(InventoryClient.class); Retryable( retryFor {RemoteAccessException.class}, noRetryFor {InventoryIllegalStateException.class}, maxAttempts 3, backoff Backoff(delay 500, multiplier 2) ) public InventoryResult deductStock(Long skuId, Integer count) { log.info(尝试扣减库存 skuId{}, count{}, skuId, count); // 这里模拟真实调用可能抛出 RemoteAccessException return doRpcDeduct(skuId, count); } Recover public InventoryResult recoverDeductStock(RemoteAccessException e, Long skuId, Integer count) { log.error(库存扣减重试耗尽执行降级逻辑 skuId{}, count{}, error{}, skuId, count, e.getMessage()); return new InventoryResult(false, -1, 库存服务暂不可用请稍后重试); } private InventoryResult doRpcDeduct(Long skuId, Integer count) { // 模拟远程调用 if (skuId % 3 0) { throw new RemoteAccessException(库存服务连接失败); } return new InventoryResult(true, 50, 扣减成功); } }这个例子虽然简化但已经覆盖了核心链路。如果 skuId 是 3 的倍数首个调用会抛 RemoteAccessException进入重试重试两次后如果仍失败Recover 方法会被执行返回一个降级结果给上层调用者。这里有个细节值得注意InventoryIllegalStateException 被配置进 noRetryFor 后即使这个异常继承了 RemoteAccessException也会被排除出重试集合。这恰好说明 retryFor 和 noRetryFor 的优先级问题——noRetryFor 的判定在异常过滤中拥有更高优先级它会先于 retryFor 做白名单排除。Spring Retry 内部会先将方法抛出的异常与 noRetryFor 列表比对命中即立刻放弃重试然后才看是否匹配 retryFor。理解这个顺序能帮你规避一些“我明明重试了怎么没走 backoff”的迷惑。3.3 恢复方法的返回值、参数与业务约定在业务类里定义 Recover 方法时要注意它的参数设计是与原方法参数一一对应的。Spring Retry 从方法签名上定位恢复方法除了第一个异常参数外其余参数的顺序、类型必须和 Retryable 方法保持一致。这会带来一条隐性的约定你在写原方法参数时要尽量让入参具备“可以组装兜底上下文”的信息比如订单号、商品 ID、用户 ID。否则恢复方法里想要记录一条有意义的日志你会发现手头什么业务标识都没有只能记一个笼统异常类型。我在设计上面的示例时特意传了 skuId 和 count就是为了让降级日志可以直接串起单据信息。还有一个返参类型问题。Recover 方法的返回值类型必须跟 Retryable 方法一致。你可以想象一下调用方并不知道你这个方法内部重试过多少次它只希望拿到一个类型安全的返回结果如果恢复方法返回类型不一致轻则抛类型转换异常重则直接破坏接口契约。曾经有同事为了省事在恢复方法里直接返回 null短时间看不出问题但下游拿到 null 后 NPE 接连出现这种坑排查起来非常费劲。正确做法是尽量返回一个包装好的降级结果对象体现业务语义而非简单的空值。关于Recover 的兜底日志我的习惯是不止记录异常栈还要记录当时的调用参数、耗时和重试次数。很多时候重试后的失败原因比首次失败更有诊断价值比如第一次是短暂网络超时第二次变成了下游服务直接拒绝连接这中间的变化恰恰暴露了下游的健康状态。如果只记录最终异常这类转发细节就完全丢失了。针对这个需求Spring Retry 官方其实提供了 RetryContext 里的内部状态但注解方式拿不到上下文所以我通常会把关键实参拼进日志再用 MDC 塞一个 traceId便于全链路检索。这也是我强调恢复方法别只写一句话的原因——它是问题根因的最后一道防线。4. 提升业务的容错深度RetryTemplate、BackOff 策略与重试治理4.1 为什么推荐在复杂场景中使用 RetryTemplateRetryable/Recover 这对注解适合大多数常规场景但当你需要更灵活的控制力时直接使用 RetryTemplate 反而更顺手。比如重试策略可能依赖上游返回的某种特殊状态码或者重试过程中想把每次失败的业务指标打点统计出来注解的声明式风格就有点力不从心了。我们在项目中经常用 RetryTemplate 处理这一类“带状态感知”的重试逻辑它把重试策略、退避策略和恢复动作拆分成多个可组合的组件你可以随时在代码里调整参数不用维护一堆分散的注解属性。用 RetryTemplate 实现同样功能的方式是显式构造 RetryTemplate设置 RetryPolicy 和 BackOffPolicy再调用 execute 方法。看一个例子Component public class OrderClient { Bean public RetryTemplate retryTemplate() { RetryTemplate template new RetryTemplate(); // 只对特定异常重试最多尝试 4 次 SimpleRetryPolicy retryPolicy new SimpleRetryPolicy(4, Collections.singletonMap(RemoteAccessException.class, true)); template.setRetryPolicy(retryPolicy); // 指数退避初始 1 秒每次乘以 2最大 8 秒 ExponentialBackOffPolicy backOffPolicy new ExponentialBackOffPolicy(); backOffPolicy.setInitialInterval(1000); backOffPolicy.setMultiplier(2.0); backOffPolicy.setMaxInterval(8000); template.setBackOffPolicy(backOffPolicy); // 设置一个监听器便于记录每次重试的情况 template.registerListener(new RetryListener() { Override public T, E extends Throwable boolean open(RetryContext context) { return true; } Override public T, E extends Throwable void onError(RetryContext context, E throwable) { log.warn(第 {} 次重试失败{}, context.getRetryCount() 1, throwable.getMessage()); } Override public T, E extends Throwable void close(RetryContext context, E throwable, T result) { // 结束时可根据 throwable 或 result 判断是否重试成功 } }); return template; } }RetryTemplate 通过 RetryListener 能拿到每次尝试的细节状态包括 RetryContext 里的重试次数、抛出的异常甚至可以控制 open 方法向后传递的条件。如果你需要把每次重试的耗时常驻到监控面板注解方式是做不到的但模板方动就这么简单。另外一个差异点是RetryTemplate 的 execute 是编码式调用异常处理完全由你控制不需要依赖 Spring 的异常翻译器去黑盒操作排错时思路会清晰很多。对我来说选注解还是选模板主要看重试逻辑的“可变复杂度”。如果一个方法只有“失败了重试几次”这种简单诉求注解是最佳解如果重试过程中还需要配合告警、动态参数、跳过某次尝试、集成自定义监听器这些复合需求模板反而更省心。团队里做技术方案时我通常会给一个比较粗的规则凡是重试参数不会频繁变动的入口方法用注解凡是重试行为要接入内部监控或带有动态获取 token 这类现场逻辑的用模板。4.2 BackOff 退避策略不同策略的取舍与参数计算backoff 是重试机制里最容易被轻视却最影响效率的部分。请求失败后的下一次尝试不是越快越好而是要结合下游恢复时间的经验值设计。Spring Retry 提供了三种主要策略FixedBackOffPolicy固定延迟、ExponentialBackOffPolicy指数延迟和 ExponentialRandomBackOffPolicy指数随机抖动。先说固定延迟它适合下游故障恢复时间相对稳定的场景比如数据库连接池被临时打满通常几百毫秒就能恢复。延迟时间可以这样估算假设下游平均恢复时间为 500 毫秒要让 90% 的异常情况都能在第二轮被消化delay 设置为恢复均值的 1 到 1.5 倍较为合适也就是 500 到 750 毫秒。太短会导致重试请求在下游还没缓过劲时就再次冲击太长则浪费宝贵的接口时延预算。其次是指数退避适用于不确定故障时间窗口的场景比如第三方 API 不稳定时先等 1 秒再等 2 秒、4 秒、8 秒以倍数递增。指数退避的核心假设在于如果下游故障不是瞬时的短时间内连续重试大概率都还会失败所以间隔越拉越大避免对下游形成持续的流量压力。带随机抖动的指数退避则是为了防止“惊群效应”。比如你同时有一百个请求都在做指数退避第一轮延迟后可能约等于同一时刻发起下一轮重试这会让下游服务刚喘口气又被流量拍晕。ExponentialRandomBackOffPolicy 在每个延迟时间上叠加一个随机偏移量使得触发重试的请求分散开。我服务的系统在下游是集群节点时通常会适量混入随机值实测下来高峰期下游的 5xx 错误率下降了不少。用代码配置也就是一行 setter 的事ExponentialRandomBackOffPolicy policy new ExponentialRandomBackOffPolicy(); policy.setInitialInterval(1000); policy.setMultiplier(2.0); policy.setMaxInterval(30000);再补充一句参数计算经验maxAttempts 和 backoff 的总耗时一定要小于调用方允许的超时时间。假设网关超时是 5 秒你配置了 4 次尝试、初始延迟 2 秒、倍数 2那么最坏情况耗时为 2 4 8 14 秒显然远远超出请求预算。这种情况下必须调小延迟或减少尝试次数。更稳妥的做法是再配一个 TimeoutRetryPolicy 或使用带超时控制的 RestTemplate让重试在上层超时前及时收手否则重试反而会拖垮整个接口的响应能力。关于这个计算步骤其实可以用一张表格简单对比一下策略使用场景常见参数参考注意点FixedBackOffPolicy下游恢复时间稳定delay500~1000ms如果恢复时间波动大容易频繁失败ExponentialBackOffPolicy不确定故障窗口initial1000ms, multiplier2.0总耗时需按等比数列估算防止超预算ExponentialRandomBackOffPolicy高并发、集群下游initial1000ms, multiplier2.0, max30s随机因子能有效打散扎堆请求4.3 用重试拦截器和指标埋点看清楚重试行为很多团队把 Retryable 接进系统后完全不清楚重试到底发生过多少次、在哪些接口上发生、每次恢复耗时几何。这其实丧失了最重要的可观测性。Spring Retry 在注解方式下提供一个扩展切入点自定义 RetryListener 并注入到容器中配置在 RetryTemplate 里可以被全局感知。但如果是注解驱动的默认重试想拿到回调常规做法是利用监听器工厂或者直接注册一个全局拦截器。我这边常用的方案是在系统里统一封装一个 RetryListener 工厂类把日志和指标全部收敛到一个地方。比如借助 Micrometer 给重试事件打 counter标记 tags接口名称、异常类型、是否最终失败。这样后续做 Grafana 监控时一眼就能看出”哪个接口重试次数异常攀升“。代码层面类似这样Component public class RetryMetricListener implements RetryListener { private final MeterRegistry meterRegistry; public RetryMetricListener(MeterRegistry meterRegistry) { this.meterRegistry meterRegistry; } Override public T, E extends Throwable void onError(RetryContext context, E throwable) { meterRegistry.counter(retry.attempts, method, context.getAttribute(retry.method) null ? unknown : context.getAttribute(retry.method).toString(), exception, throwable.getClass().getName() ).increment(); } }这个思路的价值在于重试机制不应该是黑盒。线上真正出现问题的时候你需要迅速区分是“重试不足导致失败”还是“重试过多导致过载”。有了指标以后判断就变成了数据说话。比如下游开始抖动时重试次数本身成为一个敏感信号如果单接口在几分钟内重试次数飙升多半是下游健康状态出问题了应该触发告警让值班人介入。相反如果重试次数很低但最终失败率很高则说明异常类型可能没有正确命中 retryFor需要检查配置。这里顺带补充一个通过指标排查问题的思路不能只看最终异常还要关注重试链路中的中间异常分布它们往往比结果更能说明问题。5. 高频问题与避坑指南这些年我踩过的重试“雷区”5.1 雷区一Recover 不生效异常直接抛给调用方遇到Recover 不生效时先检查恢复方法是否和原方法在同一个类中。我之前踩过的最隐蔽的一次是同事把 Retryable 方法写在了一个类里把 Recover 方法写在了该类的私有内部类中结果运行时恢复逻辑从未被触发。另外检查一下恢复方法是否被正确的 Spring 代理拦截到——如果调用方绕过 Spring 容器直接 new 了一个业务对象那别说 Recover 了Retryable 也不会生效。再然后看异常类型恢复方法的第一个参数类型必须匹配重试最终抛出的异常类型精确匹配或父类匹配都存在但尽量不要用 Exception 做万能兜底不然你无法在不同异常上构建差异化的降级逻辑。最后检查是否因为 noRetryFor 把异常排除后直接抛出了这种情况下异常在第一次失败时就脱离了重试流程Recover 自然无法介入。我给团队成员做审查时有个固定问题问得最多“你这个重试方法真的完成了三次调用还是只做了一次就进兜底”很多人在重试方法内部自己 catch 了异常并做了转换把 RemoteAccessException 转为 BizException 后抛出结果导致 retryFor 无法匹配到预期异常重试直接形同虚设。这里的关键纪律是重试方法内部不要捕获异常后自行包装让异常沿着调用栈自然往外抛交给 Spring Retry 的拦截器去判断。如果确实需要包装记得把包装后的异常类型也放进 retryFor 列表。5.2 雷区二没考虑重试的幂等性造成重复扣款或重复入账重试机制本质上会让同一个操作执行多次因此被重试的方法必须满足幂等性要求。举个最典型的例子你的业务代码里如果先“检查余额”再“扣款”重试并发时可能两次请求都通过了检查最后扣了两次款。我在设计库存扣减案例时特意强调 doRpcDeduct 需要具备业务幂等性传入事务消息的唯一业务 ID每次调用先把 ID 写入去重表如果已存在就直接返回上次的扣减结果。这里的核心原则是重试只能重放请求不能重放副作用。具体的实现思路有很多比如在数据库层面增加唯一约束或者用 Redis SETNX 做请求去重。但要注意重试时的幂等和分布式事务的幂等还不完全一样。Retryable 的重试粒度是一个方法它的外部并没有统一的事务边界所以不要在方法内部直接开一个事务并期待回滚能力。假设你的扣减方法内部已经执行了 update 语句随后调用远程发送 MQ 失败触发重试方法再次进入时第一次的数据库修改可能已经提交了。遇到这种情况我的选择是给整个处理逻辑加一个业务级的状态机从“初始”到“已扣减”再到“已通知”重试前先查状态命中终态就直接返回成功。5.3 雷区三重试导致线程池耗尽和线程阻塞压倒服务重试本身是占用当前线程的在高并发服务里一次重试可能让一个线程多存活几秒QPS 上来以后线程池很容易被打满。我遇到过某核心接口在高峰期突然 RT 飙升去查线程栈发现大量线程都阻塞在 RestTemplate 的调用等待上细看每一行都带着重试链路这就是典型的“重试风暴”。规避方式除了上面说的缩短退避时间外还可以借助异步化隔离重试线程比如把 Retryable 方法放入独立的线程池执行重试等待不再占据请求线程。但异步又会引入结果回调的复杂性所以我的经验是先估算并发峰值下的最大占用线程数如果只是偶发故障场景同步重试还是能接受的如果高频、高并发最好改造为 MQ 异步消费加重试。另外需要留意的是超时时间与重试耗时的叠加效应。假设你用了 OpenFeign 调用下游Feign 默认连接超时为 10 秒读取超时为 60 秒一旦下游卡住单次调用就会消耗很长时间若再配置多轮重试整个请求的时间线会被拉得极其恐怖。处理思路是优先调低下游调用的超时时间让重试在更小的时间片内完成。同时可以结合 Recover 做快速失败降级避免调用方无限等待。5.4 排查技巧速查表一眼定位重试配置问题下面这张表是我在团队wiki里维护的速查表遇到重试异常时先按这个顺序排查能省掉很多翻阅源码的时间现象可能原因处理建议注解写了但完全不重试缺少 EnableRetry方法未被 Spring 代理自调用加开关确认 Bean 被容器管理拆类或 AopContext重试后异常直接抛给上层Recover 不存在或不被识别异常类型不匹配检查恢复方法位置、参数顺序、异常类型无延迟地疯狂重试BackOff 策略未配置或配置错误检查注解 backoff 参数模板里检查 BackOffPolicy重试次数超过预期maxAttempts 理解有误含首次调用确认计数规则按业务需要缩小次数重试过程中产生了重复数据未做幂等处理增加唯一约束或状态机在重试入口做去重线程池阻塞接口 RT 飙升同步重试耗时过长或重试风暴缩短退避时间降级为异步重试设置外部超时某些异常不该重试却一直在重试retryFor/noRetryFor 配置不完整或异常类型过泛精确配置异常类型将已知业务异常加入 noRetryFor这个表我一直建议团队贴在项目文档里比看长篇大论顺手得多。要知道重试机制本身不复杂但一旦在生产环境出问题定位的成本往往很高。把这些常见坑提前固化下来也算是一种团队资产。5.5 补充一条动态重试参数与配置中心的联动最后再分享一个稍微进阶一点的技巧。现实场景中重试参数很少有真正一成不变的。比如下游服务稳定性变差时你可能想让 maxAttempts 从 3 变成 5又比如大促期间你希望延迟时间缩短以换取吞吐量。这时候注解上的常量就无法满足动态需求了。我个人会在项目中把重试参数抽成一个专门的配置类通过 ConfigurationProperties 从配置中心读取并在使用时构造 RetryTemplateConfigurationProperties(prefix app.retry) public class RetryProperties { private int maxAttempts 3; private long initialDelay 1000; private double multiplier 2.0; // getters and setters }然后封装一个工厂方法每次构建新的 RetryTemplate 时把配置中心的最新值传入。这种方式配合 Nacos 或 Apollo可以做到不重启服务实时调整重试力度。相比注解方案它虽然在代码上多了一点点模板味道但换来的是运维层面的灵活度。如果你所在的团队对参数调优频率较高值得往这个方向演化。6. 写在最后重试是保障但绝不是万能药我见过不少团队把 Retryable 当成一把万能钥匙任何下游报错都想着重试几下解决这是非常危险的思路。重试只能掩盖一部分暂时的故障如果下游已经进入持续不可用状态反复重试只会加剧资源消耗甚至让系统进入到“愈重试愈崩溃”的恶性循环。重试必须配合熔断、限流、降级这整套容错手段一起使用才能既保证偶发故障时的自愈能力又在持续性故障时快速止损。以我在生产环境摸爬滚打的经验这个组合的价值远超其中任何一个单独组件。Retryable 与 Recover 虽然只是两支注解但它们的完成度还是很高的。用好了代码里几乎看不到任何重试逻辑的痕迹业务方法保持干净容错优雅地埋藏在 AOP 链中用歪了则可能把简单的调用变得错综复杂甚至让你的系统在故障时表现得比没有重试更糟糕。建议你在自己的项目里先挑一个“低风险但容易抖动”的下游接口练手把参数开小观察指标逐步调优再推广到核心链路上。这种渐进式的落地方式比一上来就给所有接口加上重试要稳妥得多。我的日常实践里还有一个小习惯每次为服务接入新的下游渠道时先问三个问题——这个失败是否值得重试重试的最大总耗时是否在预算内重试时是否会产生业务副作用这三个问题过完脑子后再决定用注解还是模板、配几次重试、要不要自定义恢复逻辑。做技术方案时多留一分克制线上就能少一分慌乱。希望这篇基于真实踩坑的分享能帮你少走一些弯路。
Spring Boot重试机制全解析：从@Retryable到@Recover的工程实践
1. 为什么需要重试机制——从一次线上故障说起那天下午我的手机被运维瞬间打爆原因是线上订单服务大面积超时连带支付回调也攒了整整五千多条。事后翻日志才发现罪魁祸首是下游的库存服务在做一次全量缓存重建偶尔返回 503而我们的调用方代码里没有任何重试保护一次失败就直接把异常抛给了上层最终导致整条链路雪崩。事后复盘时组里的老大哥悠悠来了一句“这个场景要是用上 Spring 的 Retryable 就稳了。”那是我第一次真正正视 Spring 框架里的重试注解。所谓重试说白了就是当一次方法调用因为偶发的网络抖动、下游限流或瞬时故障而失败时系统自动按照预设的次数和间隔策略重新发起调用直到成功或达到最大尝试次数为止。它解决的根本矛盾是分布式环境下异常往往是“大概率事件”你的代码必须假设上下游随时可能不给面子。对于 Spring 生态的开发者来说Retryable 与 Recover 这对组合就是专门干这个的——前者标记“哪个方法需要重试”后者定义“重试彻底失败后怎么兜底”。我还记得第一次看到这对注解时的感受网上的帖子不是贴个 demo 就完事就是参数解释得云里雾里真到了自己要接入时踩了一堆莫名其妙的坑。所以这篇就按我的实操路径来写从原理讲到配置从踩坑讲到排查争取让你看完就能直接落地到项目里。这篇文章适合谁看如果你在用 Spring Boot 搭服务、写接口或者你的任务里恰好有“调用三方接口要稳定”这种需求那这篇文章就是给你准备的。哪怕你目前还没遇到过重试场景把这些知识点提前存着也能让你以后处理故障时多一张底牌。带杠精属性的朋友可能会说“重试我自己用 for 循环写不行吗”行当然行但当你需要处理退避策略、异常类型区分、回退兜底这些细节时自己手写才知道维护成本有多高。接下来我们会从设计思路上聊聊为什么选择注解方案再手把手把核心参数和恢复方法讲透最后补充高频故障的排查经验。2. 核心参数逐个拆Retryable 的选择逻辑与 Recover 的兜底边界2.1 Retryable 注解参数不是全写上就完事先看 Retryable 最基础的写法。在 Spring Boot 工程里第一步需要引入 spring-retry 依赖然后在启动类或配置类上加上 EnableRetry 开关之后才能在目标方法上使用注解。很多新手会漏了 EnableRetry结果注解写了半天完全没生效这是最经典的入门坑。配上参数之后大概是这个样子Service public class PaymentService { private static final Logger log LoggerFactory.getLogger(PaymentService.class); Retryable( retryFor {RemoteAccessException.class, TimeoutException.class}, noRetryFor {IllegalArgumentException.class}, maxAttempts 4, backoff Backoff(delay 1000, multiplier 2, maxDelay 10000) ) public String callPaymentGateway(String orderId) { // 模拟调用三方支付接口 return restTemplate.postForObject(/pay, orderId, String.class); } }这里面的参数各有各的门道。retryFor 指定哪些异常会触发重试Spring 4.3 之后推荐用它替代已废弃的 include它的底层逻辑是判断抛出的异常是否为指定异常类型或其子类。noRetryFor 则是黑名单像参数校验异常这种“重试一万次也不可能成功”的业务异常一定要塞进去不然系统会做着无意义的等待。maxAttempts 是整个重试过程最多执行多少次方法调用含第一次原始调用写 4 意味着最多打四次。最后一个 backoff 是退避策略delay 是第一轮失败后的等待毫秒数multiplier 代表每一轮延迟时间的翻倍系数maxDelay 则限制单次最大延迟防止指数爆炸。如果说参数是“规定动作”那配置这些参数背后的逻辑才是真正的“自选动作”。选哪些异常重试、选哪些不重试本质上是在回答一个问题当前场景里什么失败原因值得我多花时间等下去网络抖动、下游超时这类是值得等等的因为恢复了就没事了可业务校验不通过、数据格式错误这类你再怎么试结果都一样唯一的结局就是白白占着线程资源。我在实际项目里通常会把“可重试异常”控制在比较窄的范围内优先考虑 Spring 自带的 RemoteAccessException再根据下游具体实现补充各自的超时异常类型。做这个约定之前一定要和团队对齐光靠个人经验很容易出现“A 觉得可以重试、B 觉得不能重试”的拉扯。另一个容易被忽略的点是Retryable 默认是同步阻塞的。它对当前线程进行 sleep 式的等待并不是异步任务。如果你在一个高并发接口里对每个请求都配置了多次重试线程池可能在高峰期被打满进而引发响应延迟。所以参数不是越大越好maxAttempts 和 backoff 的组合需要结合下游的恢复时间和自身接口允许的耗时上限来综合评估。比如我遇到过一兄弟把 maxAttempts 配了 10 次、delay 配了 5 秒结果单次请求最长要等 40 多秒前端早超时放弃了后端线程却被死死占住最后靠扩大线程池才勉强缓解这就属于没有结合实际场景拍脑袋配参数。2.2 Recover 注解的场景边界与匹配机制Recover 看起来只是一个普通的兜底注解但它内部有一套严谨的匹配规则。简单说当 Retryable 方法经过指定次数的尝试后仍然失败Spring Retry 会把最后一次抛出的异常交回容器容器在同一个类里扫描被 Recover 标记的方法按参数类型匹配找到能处理当前异常的那个恢复方法执行它并返回结果。这个兜底方法最关键的限制是参数列表的第一个参数必须是被捕获的异常类型剩余参数则要和原方法的参数列表保持一致。见下面这个示例Recover public String recoverCallPaymentGateway(RemoteAccessException e, String orderId) { log.error(支付网关重试耗尽订单号{}异常{}, orderId, e.getMessage()); // 可以做降级、告警、落库等操作 return fallback; }这里有两个常见的误解。第一个误解是“只要写了 Recover 它就会自动执行”实际上如果可重试异常被 noRetryFor 排除掉了Retryable 会在第一次失败后立即抛出异常根本不会走到 Recover 这一步。第二个误解是“多个 Retryable 方法可以共用一个恢复方法”从代码层面不是绝对不行前提是异常类型与参数列表恰好能匹配上但这样会让恢复逻辑的上下文变得很模糊我个人的建议是每个方法配一个语义清晰的恢复方法宁可多写几个也别偷懒写成一个万能恢复方法不然日志里分辨兜底来源都得看半天。要知道 Recover 的“兜底”到底写在哪个位置还得理解 Spring Retry 的拦截器调用链路。Retryable 方法被调用时Spring 通过 AOP 拦截器创建了一次 RetryTemplate 的执行过程重试判断由 RetryPolicy 和 BackOffPolicy 共同决定一旦 RetryPolicy 判定“不再继续”异常会被抛给拦截器拦截器再去容器里寻找 Recover 方法。理解这个执行链路以后很多令人困惑的行为就说得通了为什么 Recover 能在注解方法内部没有 catch 的情况下接住异常因为异常根本没在原方法里被消化而是沿 AOP 链路向上传递给了恢复处理器。我刚开始用这套机制时犯过一个错把恢复方法写在另一个类里还特地用 Service 注入进来。结果 Spring 容器里扫描不到这个恢复方法重试耗尽后异常直接抛给了调用方我盯着日志查了半天没明白错误出在哪。后来翻官方文档才注意到恢复方法必须和被重试方法定义在同一个类中且该类需要被 Spring 管理。原理上其实也好理解Recover 的解析依赖方法签名所在的上下文跨类配置会让代理对象无法建立准确的映射。相比之下如果你希望恢复逻辑更解耦可以考虑直接使用 RetryTemplate 自行调用或者利用默认的 Recover 规则在同一个类内组合职责相近的多个重试方法。3. 工程落地实操Spring Boot 中从依赖引入到业务封装的完整步骤3.1 环境准备与依赖引入细节如果你用的是 Spring Boot 2.x 或 3.x引入 spring-retry 依赖并不复杂关键在于版本选择。Spring Boot 的 BOM 已经帮我们管理好了 spring-retry 的版本所以在 pom.xml 里直接写即可dependency groupIdorg.springframework.retry/groupId artifactIdspring-retry/artifactId /dependency启动类或配置类上加上 EnableRetry 注解然后项目里所有用了 Retryable 的 Bean 都会被自动代理。有一点值得提醒Spring Boot 2.x 默认不引入 AOP 相关依赖而 Retryable 的底层实现强依赖 Spring AOP所以建议同时引入 spring-boot-starter-aopdependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-aop/artifactId /dependency从 Spring Boot 2.6 左右的版本开始如果少了这个 starter运行时会报出无法找到 Advisor 相关类的异常。我个人通常会在依赖里同时看到 spring-retry 和 aop 两个身影才放心。对于只想快速尝试注解效果的新人也别忘了 Spring Boot 的自动配置只负责扫描 Bean并不会自动开启重试功能这也就是为什么第一步必须是 EnableRetry。一个让很多同学困惑的问题是为什么我引入了依赖、加了 EnableRetry但调用还是不会重试这时请你先确认自己是不是在同一个类里“自调用”——也就是内部方法之间互相调用。比如 PaymentService 的 createOrder 方法里 this.callPaymentGateway(...) 这种写法AOP 代理根本不会生效。因为 Spring AOP 的代理对象只能拦截外部对它的调用类内部 this 调用直接走的是原始对象拦截器无从插入。解决方式无非两种要么把被重试的方法抽到另一个 Spring Bean 里再注入调用要么用 AopContext.currentProxy() 获取当前代理对象进行调用。我更推荐前者代码更清晰也更容易被同事看懂。3.2 实操准备先从一个库存扣减的模拟场景开始为了更接近真实场景我设计了一个微服务里非常常见的业务调用库存服务扣减库存。这个接口偶尔会因数据库锁等待或网络超时而失败所以我们希望它在遇到小幅波动时能自己恢复同时在重试耗尽后能走一条降级路线把失败信息记录下来。先定义一个实体和接口抽象public class InventoryResult { private boolean success; private int remainStock; private String message; // 构造器、getter/setter 省略 }然后定义库存服务客户端类Component public class InventoryClient { private static final Logger log LoggerFactory.getLogger(InventoryClient.class); Retryable( retryFor {RemoteAccessException.class}, noRetryFor {InventoryIllegalStateException.class}, maxAttempts 3, backoff Backoff(delay 500, multiplier 2) ) public InventoryResult deductStock(Long skuId, Integer count) { log.info(尝试扣减库存 skuId{}, count{}, skuId, count); // 这里模拟真实调用可能抛出 RemoteAccessException return doRpcDeduct(skuId, count); } Recover public InventoryResult recoverDeductStock(RemoteAccessException e, Long skuId, Integer count) { log.error(库存扣减重试耗尽执行降级逻辑 skuId{}, count{}, error{}, skuId, count, e.getMessage()); return new InventoryResult(false, -1, 库存服务暂不可用请稍后重试); } private InventoryResult doRpcDeduct(Long skuId, Integer count) { // 模拟远程调用 if (skuId % 3 0) { throw new RemoteAccessException(库存服务连接失败); } return new InventoryResult(true, 50, 扣减成功); } }这个例子虽然简化但已经覆盖了核心链路。如果 skuId 是 3 的倍数首个调用会抛 RemoteAccessException进入重试重试两次后如果仍失败Recover 方法会被执行返回一个降级结果给上层调用者。这里有个细节值得注意InventoryIllegalStateException 被配置进 noRetryFor 后即使这个异常继承了 RemoteAccessException也会被排除出重试集合。这恰好说明 retryFor 和 noRetryFor 的优先级问题——noRetryFor 的判定在异常过滤中拥有更高优先级它会先于 retryFor 做白名单排除。Spring Retry 内部会先将方法抛出的异常与 noRetryFor 列表比对命中即立刻放弃重试然后才看是否匹配 retryFor。理解这个顺序能帮你规避一些“我明明重试了怎么没走 backoff”的迷惑。3.3 恢复方法的返回值、参数与业务约定在业务类里定义 Recover 方法时要注意它的参数设计是与原方法参数一一对应的。Spring Retry 从方法签名上定位恢复方法除了第一个异常参数外其余参数的顺序、类型必须和 Retryable 方法保持一致。这会带来一条隐性的约定你在写原方法参数时要尽量让入参具备“可以组装兜底上下文”的信息比如订单号、商品 ID、用户 ID。否则恢复方法里想要记录一条有意义的日志你会发现手头什么业务标识都没有只能记一个笼统异常类型。我在设计上面的示例时特意传了 skuId 和 count就是为了让降级日志可以直接串起单据信息。还有一个返参类型问题。Recover 方法的返回值类型必须跟 Retryable 方法一致。你可以想象一下调用方并不知道你这个方法内部重试过多少次它只希望拿到一个类型安全的返回结果如果恢复方法返回类型不一致轻则抛类型转换异常重则直接破坏接口契约。曾经有同事为了省事在恢复方法里直接返回 null短时间看不出问题但下游拿到 null 后 NPE 接连出现这种坑排查起来非常费劲。正确做法是尽量返回一个包装好的降级结果对象体现业务语义而非简单的空值。关于Recover 的兜底日志我的习惯是不止记录异常栈还要记录当时的调用参数、耗时和重试次数。很多时候重试后的失败原因比首次失败更有诊断价值比如第一次是短暂网络超时第二次变成了下游服务直接拒绝连接这中间的变化恰恰暴露了下游的健康状态。如果只记录最终异常这类转发细节就完全丢失了。针对这个需求Spring Retry 官方其实提供了 RetryContext 里的内部状态但注解方式拿不到上下文所以我通常会把关键实参拼进日志再用 MDC 塞一个 traceId便于全链路检索。这也是我强调恢复方法别只写一句话的原因——它是问题根因的最后一道防线。4. 提升业务的容错深度RetryTemplate、BackOff 策略与重试治理4.1 为什么推荐在复杂场景中使用 RetryTemplateRetryable/Recover 这对注解适合大多数常规场景但当你需要更灵活的控制力时直接使用 RetryTemplate 反而更顺手。比如重试策略可能依赖上游返回的某种特殊状态码或者重试过程中想把每次失败的业务指标打点统计出来注解的声明式风格就有点力不从心了。我们在项目中经常用 RetryTemplate 处理这一类“带状态感知”的重试逻辑它把重试策略、退避策略和恢复动作拆分成多个可组合的组件你可以随时在代码里调整参数不用维护一堆分散的注解属性。用 RetryTemplate 实现同样功能的方式是显式构造 RetryTemplate设置 RetryPolicy 和 BackOffPolicy再调用 execute 方法。看一个例子Component public class OrderClient { Bean public RetryTemplate retryTemplate() { RetryTemplate template new RetryTemplate(); // 只对特定异常重试最多尝试 4 次 SimpleRetryPolicy retryPolicy new SimpleRetryPolicy(4, Collections.singletonMap(RemoteAccessException.class, true)); template.setRetryPolicy(retryPolicy); // 指数退避初始 1 秒每次乘以 2最大 8 秒 ExponentialBackOffPolicy backOffPolicy new ExponentialBackOffPolicy(); backOffPolicy.setInitialInterval(1000); backOffPolicy.setMultiplier(2.0); backOffPolicy.setMaxInterval(8000); template.setBackOffPolicy(backOffPolicy); // 设置一个监听器便于记录每次重试的情况 template.registerListener(new RetryListener() { Override public T, E extends Throwable boolean open(RetryContext context) { return true; } Override public T, E extends Throwable void onError(RetryContext context, E throwable) { log.warn(第 {} 次重试失败{}, context.getRetryCount() 1, throwable.getMessage()); } Override public T, E extends Throwable void close(RetryContext context, E throwable, T result) { // 结束时可根据 throwable 或 result 判断是否重试成功 } }); return template; } }RetryTemplate 通过 RetryListener 能拿到每次尝试的细节状态包括 RetryContext 里的重试次数、抛出的异常甚至可以控制 open 方法向后传递的条件。如果你需要把每次重试的耗时常驻到监控面板注解方式是做不到的但模板方动就这么简单。另外一个差异点是RetryTemplate 的 execute 是编码式调用异常处理完全由你控制不需要依赖 Spring 的异常翻译器去黑盒操作排错时思路会清晰很多。对我来说选注解还是选模板主要看重试逻辑的“可变复杂度”。如果一个方法只有“失败了重试几次”这种简单诉求注解是最佳解如果重试过程中还需要配合告警、动态参数、跳过某次尝试、集成自定义监听器这些复合需求模板反而更省心。团队里做技术方案时我通常会给一个比较粗的规则凡是重试参数不会频繁变动的入口方法用注解凡是重试行为要接入内部监控或带有动态获取 token 这类现场逻辑的用模板。4.2 BackOff 退避策略不同策略的取舍与参数计算backoff 是重试机制里最容易被轻视却最影响效率的部分。请求失败后的下一次尝试不是越快越好而是要结合下游恢复时间的经验值设计。Spring Retry 提供了三种主要策略FixedBackOffPolicy固定延迟、ExponentialBackOffPolicy指数延迟和 ExponentialRandomBackOffPolicy指数随机抖动。先说固定延迟它适合下游故障恢复时间相对稳定的场景比如数据库连接池被临时打满通常几百毫秒就能恢复。延迟时间可以这样估算假设下游平均恢复时间为 500 毫秒要让 90% 的异常情况都能在第二轮被消化delay 设置为恢复均值的 1 到 1.5 倍较为合适也就是 500 到 750 毫秒。太短会导致重试请求在下游还没缓过劲时就再次冲击太长则浪费宝贵的接口时延预算。其次是指数退避适用于不确定故障时间窗口的场景比如第三方 API 不稳定时先等 1 秒再等 2 秒、4 秒、8 秒以倍数递增。指数退避的核心假设在于如果下游故障不是瞬时的短时间内连续重试大概率都还会失败所以间隔越拉越大避免对下游形成持续的流量压力。带随机抖动的指数退避则是为了防止“惊群效应”。比如你同时有一百个请求都在做指数退避第一轮延迟后可能约等于同一时刻发起下一轮重试这会让下游服务刚喘口气又被流量拍晕。ExponentialRandomBackOffPolicy 在每个延迟时间上叠加一个随机偏移量使得触发重试的请求分散开。我服务的系统在下游是集群节点时通常会适量混入随机值实测下来高峰期下游的 5xx 错误率下降了不少。用代码配置也就是一行 setter 的事ExponentialRandomBackOffPolicy policy new ExponentialRandomBackOffPolicy(); policy.setInitialInterval(1000); policy.setMultiplier(2.0); policy.setMaxInterval(30000);再补充一句参数计算经验maxAttempts 和 backoff 的总耗时一定要小于调用方允许的超时时间。假设网关超时是 5 秒你配置了 4 次尝试、初始延迟 2 秒、倍数 2那么最坏情况耗时为 2 4 8 14 秒显然远远超出请求预算。这种情况下必须调小延迟或减少尝试次数。更稳妥的做法是再配一个 TimeoutRetryPolicy 或使用带超时控制的 RestTemplate让重试在上层超时前及时收手否则重试反而会拖垮整个接口的响应能力。关于这个计算步骤其实可以用一张表格简单对比一下策略使用场景常见参数参考注意点FixedBackOffPolicy下游恢复时间稳定delay500~1000ms如果恢复时间波动大容易频繁失败ExponentialBackOffPolicy不确定故障窗口initial1000ms, multiplier2.0总耗时需按等比数列估算防止超预算ExponentialRandomBackOffPolicy高并发、集群下游initial1000ms, multiplier2.0, max30s随机因子能有效打散扎堆请求4.3 用重试拦截器和指标埋点看清楚重试行为很多团队把 Retryable 接进系统后完全不清楚重试到底发生过多少次、在哪些接口上发生、每次恢复耗时几何。这其实丧失了最重要的可观测性。Spring Retry 在注解方式下提供一个扩展切入点自定义 RetryListener 并注入到容器中配置在 RetryTemplate 里可以被全局感知。但如果是注解驱动的默认重试想拿到回调常规做法是利用监听器工厂或者直接注册一个全局拦截器。我这边常用的方案是在系统里统一封装一个 RetryListener 工厂类把日志和指标全部收敛到一个地方。比如借助 Micrometer 给重试事件打 counter标记 tags接口名称、异常类型、是否最终失败。这样后续做 Grafana 监控时一眼就能看出”哪个接口重试次数异常攀升“。代码层面类似这样Component public class RetryMetricListener implements RetryListener { private final MeterRegistry meterRegistry; public RetryMetricListener(MeterRegistry meterRegistry) { this.meterRegistry meterRegistry; } Override public T, E extends Throwable void onError(RetryContext context, E throwable) { meterRegistry.counter(retry.attempts, method, context.getAttribute(retry.method) null ? unknown : context.getAttribute(retry.method).toString(), exception, throwable.getClass().getName() ).increment(); } }这个思路的价值在于重试机制不应该是黑盒。线上真正出现问题的时候你需要迅速区分是“重试不足导致失败”还是“重试过多导致过载”。有了指标以后判断就变成了数据说话。比如下游开始抖动时重试次数本身成为一个敏感信号如果单接口在几分钟内重试次数飙升多半是下游健康状态出问题了应该触发告警让值班人介入。相反如果重试次数很低但最终失败率很高则说明异常类型可能没有正确命中 retryFor需要检查配置。这里顺带补充一个通过指标排查问题的思路不能只看最终异常还要关注重试链路中的中间异常分布它们往往比结果更能说明问题。5. 高频问题与避坑指南这些年我踩过的重试“雷区”5.1 雷区一Recover 不生效异常直接抛给调用方遇到Recover 不生效时先检查恢复方法是否和原方法在同一个类中。我之前踩过的最隐蔽的一次是同事把 Retryable 方法写在了一个类里把 Recover 方法写在了该类的私有内部类中结果运行时恢复逻辑从未被触发。另外检查一下恢复方法是否被正确的 Spring 代理拦截到——如果调用方绕过 Spring 容器直接 new 了一个业务对象那别说 Recover 了Retryable 也不会生效。再然后看异常类型恢复方法的第一个参数类型必须匹配重试最终抛出的异常类型精确匹配或父类匹配都存在但尽量不要用 Exception 做万能兜底不然你无法在不同异常上构建差异化的降级逻辑。最后检查是否因为 noRetryFor 把异常排除后直接抛出了这种情况下异常在第一次失败时就脱离了重试流程Recover 自然无法介入。我给团队成员做审查时有个固定问题问得最多“你这个重试方法真的完成了三次调用还是只做了一次就进兜底”很多人在重试方法内部自己 catch 了异常并做了转换把 RemoteAccessException 转为 BizException 后抛出结果导致 retryFor 无法匹配到预期异常重试直接形同虚设。这里的关键纪律是重试方法内部不要捕获异常后自行包装让异常沿着调用栈自然往外抛交给 Spring Retry 的拦截器去判断。如果确实需要包装记得把包装后的异常类型也放进 retryFor 列表。5.2 雷区二没考虑重试的幂等性造成重复扣款或重复入账重试机制本质上会让同一个操作执行多次因此被重试的方法必须满足幂等性要求。举个最典型的例子你的业务代码里如果先“检查余额”再“扣款”重试并发时可能两次请求都通过了检查最后扣了两次款。我在设计库存扣减案例时特意强调 doRpcDeduct 需要具备业务幂等性传入事务消息的唯一业务 ID每次调用先把 ID 写入去重表如果已存在就直接返回上次的扣减结果。这里的核心原则是重试只能重放请求不能重放副作用。具体的实现思路有很多比如在数据库层面增加唯一约束或者用 Redis SETNX 做请求去重。但要注意重试时的幂等和分布式事务的幂等还不完全一样。Retryable 的重试粒度是一个方法它的外部并没有统一的事务边界所以不要在方法内部直接开一个事务并期待回滚能力。假设你的扣减方法内部已经执行了 update 语句随后调用远程发送 MQ 失败触发重试方法再次进入时第一次的数据库修改可能已经提交了。遇到这种情况我的选择是给整个处理逻辑加一个业务级的状态机从“初始”到“已扣减”再到“已通知”重试前先查状态命中终态就直接返回成功。5.3 雷区三重试导致线程池耗尽和线程阻塞压倒服务重试本身是占用当前线程的在高并发服务里一次重试可能让一个线程多存活几秒QPS 上来以后线程池很容易被打满。我遇到过某核心接口在高峰期突然 RT 飙升去查线程栈发现大量线程都阻塞在 RestTemplate 的调用等待上细看每一行都带着重试链路这就是典型的“重试风暴”。规避方式除了上面说的缩短退避时间外还可以借助异步化隔离重试线程比如把 Retryable 方法放入独立的线程池执行重试等待不再占据请求线程。但异步又会引入结果回调的复杂性所以我的经验是先估算并发峰值下的最大占用线程数如果只是偶发故障场景同步重试还是能接受的如果高频、高并发最好改造为 MQ 异步消费加重试。另外需要留意的是超时时间与重试耗时的叠加效应。假设你用了 OpenFeign 调用下游Feign 默认连接超时为 10 秒读取超时为 60 秒一旦下游卡住单次调用就会消耗很长时间若再配置多轮重试整个请求的时间线会被拉得极其恐怖。处理思路是优先调低下游调用的超时时间让重试在更小的时间片内完成。同时可以结合 Recover 做快速失败降级避免调用方无限等待。5.4 排查技巧速查表一眼定位重试配置问题下面这张表是我在团队wiki里维护的速查表遇到重试异常时先按这个顺序排查能省掉很多翻阅源码的时间现象可能原因处理建议注解写了但完全不重试缺少 EnableRetry方法未被 Spring 代理自调用加开关确认 Bean 被容器管理拆类或 AopContext重试后异常直接抛给上层Recover 不存在或不被识别异常类型不匹配检查恢复方法位置、参数顺序、异常类型无延迟地疯狂重试BackOff 策略未配置或配置错误检查注解 backoff 参数模板里检查 BackOffPolicy重试次数超过预期maxAttempts 理解有误含首次调用确认计数规则按业务需要缩小次数重试过程中产生了重复数据未做幂等处理增加唯一约束或状态机在重试入口做去重线程池阻塞接口 RT 飙升同步重试耗时过长或重试风暴缩短退避时间降级为异步重试设置外部超时某些异常不该重试却一直在重试retryFor/noRetryFor 配置不完整或异常类型过泛精确配置异常类型将已知业务异常加入 noRetryFor这个表我一直建议团队贴在项目文档里比看长篇大论顺手得多。要知道重试机制本身不复杂但一旦在生产环境出问题定位的成本往往很高。把这些常见坑提前固化下来也算是一种团队资产。5.5 补充一条动态重试参数与配置中心的联动最后再分享一个稍微进阶一点的技巧。现实场景中重试参数很少有真正一成不变的。比如下游服务稳定性变差时你可能想让 maxAttempts 从 3 变成 5又比如大促期间你希望延迟时间缩短以换取吞吐量。这时候注解上的常量就无法满足动态需求了。我个人会在项目中把重试参数抽成一个专门的配置类通过 ConfigurationProperties 从配置中心读取并在使用时构造 RetryTemplateConfigurationProperties(prefix app.retry) public class RetryProperties { private int maxAttempts 3; private long initialDelay 1000; private double multiplier 2.0; // getters and setters }然后封装一个工厂方法每次构建新的 RetryTemplate 时把配置中心的最新值传入。这种方式配合 Nacos 或 Apollo可以做到不重启服务实时调整重试力度。相比注解方案它虽然在代码上多了一点点模板味道但换来的是运维层面的灵活度。如果你所在的团队对参数调优频率较高值得往这个方向演化。6. 写在最后重试是保障但绝不是万能药我见过不少团队把 Retryable 当成一把万能钥匙任何下游报错都想着重试几下解决这是非常危险的思路。重试只能掩盖一部分暂时的故障如果下游已经进入持续不可用状态反复重试只会加剧资源消耗甚至让系统进入到“愈重试愈崩溃”的恶性循环。重试必须配合熔断、限流、降级这整套容错手段一起使用才能既保证偶发故障时的自愈能力又在持续性故障时快速止损。以我在生产环境摸爬滚打的经验这个组合的价值远超其中任何一个单独组件。Retryable 与 Recover 虽然只是两支注解但它们的完成度还是很高的。用好了代码里几乎看不到任何重试逻辑的痕迹业务方法保持干净容错优雅地埋藏在 AOP 链中用歪了则可能把简单的调用变得错综复杂甚至让你的系统在故障时表现得比没有重试更糟糕。建议你在自己的项目里先挑一个“低风险但容易抖动”的下游接口练手把参数开小观察指标逐步调优再推广到核心链路上。这种渐进式的落地方式比一上来就给所有接口加上重试要稳妥得多。我的日常实践里还有一个小习惯每次为服务接入新的下游渠道时先问三个问题——这个失败是否值得重试重试的最大总耗时是否在预算内重试时是否会产生业务副作用这三个问题过完脑子后再决定用注解还是模板、配几次重试、要不要自定义恢复逻辑。做技术方案时多留一分克制线上就能少一分慌乱。希望这篇基于真实踩坑的分享能帮你少走一些弯路。
