Resilience4J Retry预期行为咨询及配置后不重试问题排查

问题1：要使重试功能正常工作，是否必须实现fallback方法？ #

• 不需要。fallback是重试全部失败后的降级逻辑，属于可选配置，和重试功能本身的触发没有任何关联，不配置fallback完全不影响重试正常运行。

问题2：异常直接抛出属于预期行为吗？是否操作有误？ #

你两次配置都存在操作错误，才导致重试未生效，具体原因和修复方案如下：

第一次配置未触发重试的常见原因 #

• Spring AOP切面未生效：@Retry是基于AOP实现的注解，只有被Spring代理对象调用的public方法才会触发切面逻辑。如果是类内部通过this调用该方法、方法非public，重试都不会生效。
• 配置的重试次数不符合预期：你配置的maxAttempts: 3指的是总调用次数为3次，也就是初始调用1次 + 额外重试2次，不是你预期的额外重试3次。如果要实现额外重试3次，需要将maxAttempts调整为4。
• 异常匹配问题：确认抛出的异常确实是配置的HttpServerErrorException及其子类，没有被代码中其他try-catch逻辑提前捕获吞掉。

第二次添加fallback后的问题 #

你当前的fallback写法逻辑错误：fallback是所有重试耗尽后才会执行的逻辑，你在fallback中直接调用原接口的逻辑不在重试切面的管辖范围内，所以不会触发重试，每次调用失败后直接走fallback、fallback调用接口再抛异常就直接返回给调用方，自然达不到重试的效果。

最终修复方案 #

不需要配置fallback，改回最初的代码结构，按以下要求调整即可：

1. 确保getCustomer方法是public修饰，且调用该方法的对象是从Spring容器中获取的Bean，不是类内部的this调用
2. 若需要额外重试3次，将yaml配置中的maxAttempts改为4
3. 无需额外配置fallback，所有重试全部失败后，Resilience4j会自动将最后一次的异常抛给服务调用方，完全符合你的需求。

内容的提问来源于stack exchange，提问作者FerdTurgusen