失败重试方案spring-retry

Pytest-rerunfailures:优化测试稳定性的失败重试工具 笔者在执行自动化测试用例时,会发现有时候用例失败并非代码问题,而是由于服务正在发版,导致请求失败,从而降低了自动化用例的稳定性,最后还要花时间定位到底是自身case的原因还是业务逻辑问题,还是其他原因,增加了定位成本。增加容错机制,失败重试,会解决大部分由于网络原因、服务重启等原因造成的case失败问题。那该如何增加失败重试机制呢?带着问题我们一起探索。 阅读详情

在后台对接第三方接口时,由于网络波动等原因,经常会出现请求超时的情况,但是有些接口不能因为一次超时就判定为失败,通常都会有重试,比如连续请求三次都失败,才认为请求失败。

方案一:在代码中进行逻辑判断

以前在处理这类问题的时候,我们大多采用的是这种方案。即设置一个重试次数,然后每次调用后判断是否调用成功,如果调用失败且没有超过重试次数,则重试调用。如下

@Test
void invoke() {
    int failCount = 0;
    while (failCount < 3) {
        if (doInvoke()) {
            break;
        }
        failCount++;
    }
    // 连续三次失败,记录失败日志
    // logService.saveLog(...)
}

boolean doInvoke() {
    // 模拟远程调用
    boolean b = new Random().nextBoolean();
    log.info("doInvoke result : {}", b);
    return b;
}

方案二:框架自带重试机制

在微服务架构中,几乎所有框架都支持超时重试,如dubbo、springcloud的feign都有超时重试机制。作为服务的调用方,我们可以不考虑接口的幂等性,默认为提供方已经做好了幂等处理,这时候我们只需要设置一下超时时间和重试次数即可。如

@DubboReference(retries = 2)
private OrderInfoService orderInfoService;

方案三:使用spring retry

spring retry原先是springbatch中的一个模块,后来被独立出来,使用非常简单,也是本文主要介绍的用法。

需要添加如下maven依赖,然后在启动类或配置类上添加@EnableRetry注解

<dependency>
    <groupId>org.springframework.retry</groupId>
    <artifactId>spring-retry</artifactId>
    <version>1.3.1</version>
</dependency>
<dependency>
    <groupId>org.aspectj</groupId>
    <artifactId>aspectjweaver</artifactId>
    <version>1.9.7</version>
</dependency>

只需要重点关注其中的两个注解@Retryable和@Recover,前者指定重试次数和重试生效条件以及重试时间间隔等,后者一般作为失败后的日志记录或失败补偿。

使用示例如下:

@Slf4j
@Service
public class PayService {

    long start = 0;

    @Retryable(recover = "recoverTest",
            value = IllegalArgumentException.class,
            maxAttempts = 10,
            backoff = @Backoff(value = 1000L, maxDelay = 5000L, multiplier = 1.5))
    public boolean pay() {
        if (start == 0) {
            start = System.currentTimeMillis();
        }
        // 记录前后间隔时间
        log.info("pay....{}", System.currentTimeMillis() - start);
        start = System.currentTimeMillis();
        throw new IllegalArgumentException("问题不大...");
    }

    @Recover
    public boolean recoverTest(IllegalArgumentException e) {
        log.info("recover...{}", e.getMessage());
        return false;
    }
}

其中,@Retryable的recover指定了所有重试均失败后的回调方法,如果@Retryable标注方法调用成功了,则不会调用@Recover注解标注的方法,与原方法的返回类型一样,@Recover注解标注的方法入参与@Retryable注解标注方法中的value或include属性指定的异常类型对应,maxAttempts指定最大重试次数,默认为3,backoff指定重试时间间隔等,如上述示例中,重试间隔时间每次都是上一次的1.5倍,且最大不超过5秒。

执行后日志如下

2022-02-16 10:51:03.045  INFO 9224 --- [           main] com.example.service.PayService           : pay....0
2022-02-16 10:51:04.046  INFO 9224 --- [           main] com.example.service.PayService           : pay....1000
2022-02-16 10:51:05.546  INFO 9224 --- [           main] com.example.service.PayService           : pay....1500
2022-02-16 10:51:07.796  INFO 9224 --- [           main] com.example.service.PayService           : pay....2250
2022-02-16 10:51:11.171  INFO 9224 --- [           main] com.example.service.PayService           : pay....3375
2022-02-16 10:51:16.171  INFO 9224 --- [           main] com.example.service.PayService           : pay....5000
2022-02-16 10:51:21.171  INFO 9224 --- [           main] com.example.service.PayService           : pay....5000
2022-02-16 10:51:26.171  INFO 9224 --- [           main] com.example.service.PayService           : pay....5000
2022-02-16 10:51:31.171  INFO 9224 --- [           main] com.example.service.PayService           : pay....5000
2022-02-16 10:51:36.171  INFO 9224 --- [           main] com.example.service.PayService           : pay....5000
2022-02-16 10:51:36.171  INFO 9224 --- [           main] com.example.service.PayService           : recover...问题不大...

@Retryable注解中还有其他属性,如支持表达式的exceptionExpression,例如在该注解中添加exceptionExpression = "message.contains('出大问题啦...')",则将不会进行异常重试,因为异常错误信息不匹配。至于其他的属性,就不再举例了,很少用到,上面这些个属性几乎足够用了。

Spring Boot项目里,用Spring-Retry优雅处理第三方API调用失败(附完整配置与避坑点) 本文详细介绍了在Spring Boot项目中如何使用Spring-Retry框架优雅处理第三方API调用失败问题。通过实战案例讲解差异化重试策略配置、降级处理方案及生产环境避坑点,帮助开发者提升系统稳定性与用户体验。重点涵盖重试框架的核心配置、幂等性处理、超时优化等关键技巧。 阅读详情

相关推荐

RuoYi-Cloud微服务消息中心架构设计与优化实践

消息中心作为企业级系统的关键组件,其架构设计直接影响系统的扩展性和可靠性。本文从微服务架构下的消息处理原理出发,探讨如何通过分层设计和分表策略解决传统单表结构的性能瓶颈。技术方案采用Spring Cloud生态实现消息路由与通道隔离,结合Redis幂等控制和Spring Retry重试机制保障消息可靠性。在RuoYi-Cloud实际案例中,该方案使吞吐量提升6倍至3000 TPS,同时支持邮件、短信等多通道扩展。特别针对高并发场景,详细介绍了批量处理、读写分离等优化手段,为分布式系统消息模块设计提供可复用的

weixin_33827590的博客 419

Spring-Retry机制@Recover及@Retryable可能未生效原因

Spring-Retry机制@Recover及@Retryable可能未生效原因

zss123yq的博客 1万+

Java集成ZXing与Minio实现二维码动态生成与云存储实践

二维码技术作为数据编码与识别的成熟方案,其核心原理是将文本、链接等信息编码成特定几何图形,通过图像传感器快速读取。ZXing作为Google开源的二维码处理库,提供了稳定高效的生成与解析能力,是Java生态中的首选工具。在分布式架构中,文件存储常面临扩展性与访问便捷性的挑战,对象存储技术以其高可用、易扩展的特性成为解决方案。Minio作为轻量且兼容S3协议的对象存储服务,便于私有化部署与集成。结合ZXing生成二维码图片,并通过Minio Java SDK实现文件上传与管理,能够构建从生成到持久化的完整链路

bangtuo9862的博客 401

NacosRule规则导致spring-retry失败踩坑

本文记录springcloud使用RestTemplate请求测试服务重试过程中, 配置NacosRule 权重规则导致spring-retry执行失败踩坑经历测试springcloud重试机制通过引入spring-retry能够自动请求超时重试其他可用节点。 测试配置问题: 使用ribbon得默认策略可以正常使用。但是使用NacosRule作为ribbon负载均衡策略情况下,会出现概率性失效。报错如下 分析: 通过控制台RetryTemplate有执行日志,说明retry机制是有被触发。连接超时报错,

Myron_007的博客 1041

Spring 的 @Scheduled 注解是否支持失败重试

虽然@Scheduled本身不支持失败重试,但通过Spring Retry 库手动重试逻辑或异步任务配置可以灵活实现该功能。实际开发中推荐优先使用@Retryable注解,其配置简洁且支持退避策略,适用于大多数场景。

ma451152002的专栏 893

保姆级教程:用K210麦克风阵列模块实现声源定位(附完整Python代码与坐标计算)

本教程详细介绍了如何使用K210麦克风阵列模块实现高精度声源定位,包括硬件连接、算法解析与实战代码。通过Python代码示例,展示了从原始数据获取到三维空间坐标计算的完整流程,适用于智能家居、机器人导航等场景。

weixin_42558093的博客 228

失败重试spring-retry

失败重试spring-retry

不如自成宇宙 495

Cadence导入tsmcN65GP PDK的完整流程与常见问题解析

本文详细介绍了Cadence导入tsmcN65GP PDK的完整流程,包括文件解压、目录结构解析、安装脚本运行及Cadence集成配置。重点解析了常见问题如文件路径错误、权限问题和工艺库显示不全的解决方案,并提供了实战技巧与优化建议,帮助用户高效完成PDK安装与配置。

weixin_29215391的博客 546

失败重试的策略(方法)

业务中往往会遇到失败重试的场景,如dubbo调用,默认3次重试,但是有些情况我们不能做重试操作,如被调用的接口不幂等。dubbo失败重试有它的固有缺陷,如:同步重试。往往很多场景并不需要同步的阻塞重试,可以尝试异步重试。本文尝试总结几种自动重试的方法。 正文 朴素方法 朴素就是代码一把梭,不考虑扩展性,重用性。 // 指定最大重试次数,成功就返回。 for (i = 0; i < retry...

Bpazy的博客 3001

【自然语言处理(NLP)实战】LSTM网络实现中文文本情感分析(手把手与教学超详细)

在当今数字化时代,人们在社交媒体、评论平台以及各类在线交流中产生了海量的文本数据。这些数据蕴含着丰富的情感信息,从而成为了深入理解用户态度、市场趋势,甚至社会情绪的宝贵资源。自然语言处理(NLP)的发展为我们提供了强大的工具,使得对文本情感进行分析成为可能。在这个领域中,长短时记忆网络(LSTM)凭借其能够捕捉文本序列中长距离依赖关系的能力,成为了情感分析任务中的一项重要技术。通过详细的步骤和示例代码,深入了解如何处理中文文本数据、构建LSTM模型、进行训练和评估。

halo的博客 2万+

DCA1000EVM数据采集实战:从mmWave Studio配置到MATLAB后处理的全链路解析

本文详细解析了DCA1000EVM数据采集的全流程,从mmWave Studio配置到MATLAB后处理,涵盖数据存储结构解析、后处理引擎剖析及Python数据处理方案。通过实战案例,帮助开发者高效处理毫米波雷达原始数据,实现从数据到应用价值的转化,提升开发效率。

weixin_33743661的博客 708

spring-retry:超时失败时的重试方案

https://github.com/spring-projects/spring-retry 官网 https://blog.youkuaiyun.com/hero272285642/article/details/100032605

qq_33451990的博客 539

易康eCognition9.0分类|规则集和机器学习的方法的面向对象的多尺度分割分类

基于易康eCognition9.0软件的规则集和机器学习的方法的面向对象的多尺度分割分类

weixin_46493028的博客 1万+

Kafka 实践中的那些坑:重试、死信队列、反压问题全收录

如果消费失败,Consumer 不提交 offset,Kafka 会不断尝试重新投递同一条消息,直到消费成功或服务挂掉。Kafka 本身不支持延迟消息,可借助定时任务、调度服务(如 Quartz)、或使用中间件如Kafka Delay Queue 实现。在生产环境中使用 Kafka 时,绝不仅仅是 “生产消息 → 消费消息” 这么简单。这是一个非常实用的问题,尤其是在微服务系统中处理消息失败与自动重试时,的组合可以大幅提升健壮性与灵活性。,无需手动创建多个重试 topic,也不必手动编排转发逻辑。

小健学Java的博客 1907

主动式桥梁防船撞预警系统的方案汇总

本系统以精密光电测高前端(2台,上下游各1台)、固态雷达(2台,上下游各1台)、AIS(1台)、偏航辅助前端(4台,上下游各2台)为核心,通过人工智能,对画面上的船舶目标进行深度学习、精确定位,再用系统集成方法将各设备有机结合在一起,构建成套的桥梁防撞主动预警系统,全天候监控过往船舶。主动式桥梁防船撞预警系统主要船舶监测采集单元、控制单元、船舶超高、偏航信息检测单元、以及视频监控单元组成,,通过声光警示、短信文字、船舶身份识别及海事对讲频道、视频录像取证等多种手段与船舶进行信息互动,主动防止船舶碰撞桥梁!

gdxixun的博客 975

软件崩溃时Visual Studio中看不到有效的调用堆栈,使用Windbg动态调试去分析定位

当在Visual Studio中遇到软件崩溃且无法查看详细调用堆栈时,可以使用Windbg进行动态调试去分析定位问题。

dvlinker的技术专栏 1万+

Kafka 实践 - 重试、死信队列、反压问题

Kafka 实践 - 重试、死信队列、反压问题

weixin_46619605的博客 2225

【零基础学习CAPL】——弹窗信息提示

不用手动制作Panel窗口,直接使用CAPL脚本实现弹窗提示。//没有wait超时,等待测试人员确认//有wait超时,对话框在超时后自动终止//有wait超时,可以显示一个资源,即对话框可以显示额外的信息。/*参数说明text:显示在弹窗中的内容,长度限制在4096字符timeout:弹窗自动结束的时间,单位:ms。若为0,则无超时控制heading:对话框文本上方的标题。字符串最大长度限制在256个字符。resource:URL或文件路径。字符串的最大长度是有限的(512个字符)。

LOVE135149的博客 264

常用的接口重试方案!

某个电商平台的订单退款接口突发异常,因为银行系统网络抖动,退款请求连续失败。原本技术团队只是想“好心重试几次”,结果开发小哥写的重试代码竟疯狂调用了银行的退款接口近百次!最终导致用户账户重复退款,平台损失过百万。老板在复盘会上质问:“接口重试这么基础的事,为什么还能捅出大篓子?大家哑口无言,因为所有人都以为只要加个for循环,再睡几秒就完事了……这篇文章跟大家一起聊聊重试的7种常用方案,希望对你会有所帮助。重试就像机房里的灭火器——永远不希望用到它,但必须保证关键时刻能救命。我们工作中选择哪种方案?

weixin_51582215的博客 558

visio安装包

Microsoft Office Visio 是一款专业的制图软件。利用经过更新的形状、协作工具和数据链接图表,创建专业级图表以简化复杂的信息。

VC中sqlite的使用

在VC中对sqlite的使用,实现数据库大批数据的快速插入,读取数据库中的数据在ListCtrl中显示

spring-retry @Recover参数传递

在@Recover中获取到传递给@Retryable方法的参数

LOOPY_Y的博客 2899

温度PID控制PLC程序

温度PID稳定控制程序,适用于欧姆龙PLC,对其他PLC也具有很大参考价值

Hystrix - 重试与熔断的冲突:为什么 Hystrix 不推荐内置重试

Hystrix - 重试与熔断的冲突解析 摘要 本文探讨了Hystrix为何不推荐内置重试机制的设计考量。作为Netflix开源的容错库,Hystrix通过断路器模式实现服务熔断、降级和资源隔离,有效防止微服务雪崩效应。然而,Hystrix在设计上刻意避免内置重试功能,主要原因在于: 重试会掩盖真实故障:多次重试可能延迟熔断器触发,导致问题恶化 资源消耗问题:重试会增加线程池和系统资源压力 监控指标失真:重试会导致失败率等关键指标统计不准确 超时冲突:重试可能使总耗时超过Hystrix配置的超时阈值 文章通

千淘万漉虽辛苦,吹尽狂沙始到金 2万+

ET2012新版免狗免安装绿色软件

ET2012新版免狗免安祖昂绿色软件。,新界面,新视觉,

瞧瞧别人家的接口重试,那叫一个优雅!

后续还会上新更多项目,目标是将 Java 领域典型的项目都整一波,如秒杀系统, 在线商城, IM 即时通讯,Spring Cloud Alibaba 等等,后续还会上新更多项目,目标是将 Java 领域典型的项目都整一波,如秒杀系统, 在线商城, IM 即时通讯,Spring Cloud Alibaba 等等,记得五年前的一个深夜,某个电商平台的订单退款接口突发异常,因为银行系统网络抖动,退款请求连续失败。对于有些不需要实时反馈,允许批量处理的任务(如文件导入)的业务场景,我们可以使用定时任务。

犬小哈 150

Java后端如何实现美团外卖API调用失败时的自动重试与补偿机制

首先,我们定义一个与外卖平台交互的服务接口。/*** 外卖订单服务接口*//*** 创建外卖订单* @param userId 用户ID* @param amount 订单金额* @return 订单号* @throws Exception 调用失败时抛出异常*/

69

SpringBoot RestTemplate 对应问题和解决方案

SpringBoot RestTemplate 相关问题和解决思路 采用spring resttemplate方案,适用场景 被调服务端需要Bearer token验证的方案设计 被调服务端需要SSL验证的架构设计 如何实现请求失败重试,利用spring retry 如何快速进行模型转换,避免adapter,setter and getter. 如何对接口和...

weixin_30748995的博客 509

RabbitMQ--消费者可靠性

消费者的可靠性,主要分为消费者的确认机制,消息消费失败之后的处理策略,在一些非幂等性的操作时如何保证消息消费的幂等性。

Mai_Jun_Hao的博客 920

实现重试只知道Spring Retry?试试Spring Boot 整合 Fast Retry 来实现重试机制

在外面日常开发中,服务之间的调用往往存在延迟和失败的情况。比如之前博主写的一篇【Spring Boot集成 Spring Retry 实现容错重试机制并附源码】短信发送远程服务调用争抢锁网络延迟服务宕机或临时故障等问题。为了提高服务的可靠性,我们可以使用重试机制来处理这些问题,之前我们已经介绍了,今天我们介绍另外一款轻量级的Fast Retry库。Fast Retry是一个轻量级的 Java 重试库,它可以方便地为方法调用添加重试机制。

Micro麦可乐的博客 1万+
上一篇: AOP+注解+SpringEL表达式记录操作日志
下一篇: springboot+redis主从复制、哨兵、读写分离
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值