非常简洁地重试Retry组件,使用起来杠杠的
liuian 2025-06-15 17:36 4 浏览
前言
小伙伴是不是经常遇到接口调用异常,超时的场景?尤其网络抖动导致timeout超时的场景,我们一般产品就会叫我们要重试几次。
很多小伙伴的实现方式是写个循环调用
for(int i=1;i<=3;i++){
try{
if(doExec()){
break;
}
}catch{
}
}
这种实现方式是比较简单,但非常不灵活,不能针对很多种场景。今天老顾给大家带来一个retry重试组件,流行度很高,即是guava-retrying组件。功能简洁强大,是出门旅行的必备工具。
依赖引用
<dependency>
<groupId>com.github.rholder</groupId>
<artifactId>guava-retrying</artifactId>
<version>2.0.0</version>
<!-- 排除与guava重复的依赖 -->
<!-- <exclusions>-->
<!-- <exclusion>-->
<!-- <groupId>com.google.guava</groupId>-->
<!-- <artifactId>guava</artifactId>-->
<!-- </exclusion>-->
<!-- <exclusion>-->
<!-- <groupId>com.google.code.findbugs</groupId>-->
<!-- <artifactId>jsr305</artifactId>-->
<!-- </exclusion>-->
<!-- </exclusions>-->
</dependency>
guava-retrying包中应用有相关的guava版本依赖,如果和自身项目冲突可以排除
示例
执行方法
@Service
public class RetryService {
private static Logger logger = LoggerFactory.getLogger(RetryService.class);
private AtomicInteger count = new AtomicInteger(0);
public int doExec(){
logger.info("调用了{}次",count.incrementAndGet());
if (count.get() % 2 == 0){
throw new Exception("----->异常了哦");
}
return count.get();
}
}
里面定义了doExec方法,每次调用count加1,如果是2的倍数就抛异常。
调用方法
public String test01(){
Retryer<Integer> retryer = RetryerBuilder.<Integer>newBuilder()
.retryIfRuntimeException()
//retryIfResult 表达式返回true,则重试
.retryIfResult(result -> {
if (result % 3 == 0){
logger.info("----->应该重试了");
return true;
}
return false;
})
.withStopStrategy(StopStrategies.stopAfterAttempt(3))
.build();
try {
retryer.call(() -> retryService.doExec());
} catch (ExecutionException e) {
logger.error("异常1:{}",e.getMessage());
} catch (RetryException e) {
logger.error("异常:{}",e.getMessage());
}
return "ok";
}
从上面代码中,我们就可以实现条件重试。
guava的retry的思想可分为重试条件、停止重试策略、重试间隔策略
一、重试条件
表示在什么情况下,进行重试。retry组件中的RetryerBuilder的retryIfXXX()方法用来设置在什么情况下进行重试,总体上可以分为根据执行异常进行重试和根据方法执行结果进行重试两类。
根据异常重试
1、retryIfException() 当方法执行抛出异常Exception时重试
2、retryIfRuntimeException()当方法执行抛出异常RuntimeException时重试
3、retryIfExceptionOfType(exceptionClass)当方法执行抛出异常具体哪个异常时重试
4、retryIfException(Predicate p)自定义异常什么情况下重试
根据返回结果重试
retryIfResult(@Nonnull Predicate<V> resultPredicate)根据返回值判断是否重试。
//返回true时,重试
.retryIfResult(result -> {
if (result % 3 == 0){
logger.info("----->应该重试了");
return true;
}
return false;
})
上面的result代表的是返回值,判断返回值对3取余,返回true时则进行重试。
二、停止重试策略
重试组件需要提供停止重试的策略withStopStrategy,最简单的方式就是重试几次
1、StopAfterAttemptStrategy
从字面上面就知道什么意思,即在执行次数达到指定次数之后停止重试。
.withStopStrategy(StopStrategies.stopAfterAttempt(3))
2、NeverStopStrategy
此策略永远重试,一直重试
.withStopStrategy(StopStrategies.neverStop())
3、StopAfterDelayStrategy
设定一个最长允许的执行时间;比如设定最长执行10s,无论任务执行次数,只要重试的时候与第一次执行的时间差,超出了最长时间,则任务终止,并返回重试异常RetryException
.withStopStrategy(StopStrategies.stopAfterDelay(10,TimeUnit.SECONDS))
三、重试间隔策略
在重试场景中,我们最好有个重试的间隔,如果没有间隔,很有可能连续的重试都会失败。
WaitStrategy
1、FixedWaitStrategy
固定时长重试间隔
.withWaitStrategy(WaitStrategies.fixedWait(1,TimeUnit.SECONDS))
上面即是重试间隔为1秒
2、RandomWaitStrategy
随机的间隔时长
.withWaitStrategy(WaitStrategies.randomWait(1,TimeUnit.SECONDS,5,TimeUnit.SECONDS))
第1个参数是最小间隔时长,第二个参数最大间隔时长;介于两者之间随机取一个时长
3、IncrementingWaitStrategy
递增间隔时长,即每次任务重试间隔时间逐步递增,越来越长
.withWaitStrategy(WaitStrategies.incrementingWait(3, TimeUnit.SECONDS,1,TimeUnit.SECONDS))
该策略输入一个起始间隔时间值和一个递增步长,然后每次等待的时长都递增increment时长
4、ExceptionWaitStrategy
根据不同的异常,决定不同的间隔时长
.withWaitStrategy(WaitStrategies.exceptionWait(Exception.class, new Function<Exception, Long>() {
@Override
public @Nullable Long apply(@Nullable Exception input) {
if (input instanceof NullPointerException){
return 1 * 1000L;
}else if (input instanceof IndexOutOfBoundsException){
return 2 * 1000L;
}else if (input instanceof IllegalStateException){
return 3 * 1000L;
}
return 0L;
}
}))
上面的代码 一看就知道了。
上面是常见的等待策略,还有几个不常用的等待策略,小伙伴们自行查阅。
到了这里,我们感觉还缺失了非常重要的一个模块;即是我们能否知道任务有没有经过重试?或者我们需要记录一下重试次数,或者重试的时候,弄一个error日志告警,帮助我们关注系统的稳健。
我们来介绍一下重试监听器
重试监听器RetryListener
当发送重试时,会调用RetryListener的onRetry方法,这样的话我们就可以做一些自定义的重试的额外任务。
定义一个类,继承RetryListener接口
public class MyRetryListener implements RetryListener {
private static Logger logger = LoggerFactory.getLogger(MyRetryListener.class);
@Override
public <Integer> void onRetry(Attempt<Integer> attempt) {
if (attempt.hasResult()){
logger.info("===>方法返回的结果:{}",attempt.getResult());
}
if (attempt.hasException()){
logger.info("===>第{}次执行,异常:{}",attempt.getAttemptNumber(),attempt.getExceptionCause()==null ? "" : attempt.getExceptionCause().getMessage());
return;
}
logger.info("===>第{}次执行",attempt.getAttemptNumber());
}
}
在RetryerBuilder中加入
.withRetryListener(new MyRetryListener())
这样就实现了监听业务
重试原理
guava-retrying的组件功能还是比较强大的,我们可以看一下核心的代码
public V call(Callable<V> callable) throws ExecutionException, RetryException {
long startTime = System.nanoTime();
// 执行次数从1开始
for (int attemptNumber = 1; ; attemptNumber++) {
Attempt<V> attempt;
try {
// 尝试执行
V result = attemptTimeLimiter.call(callable);
// 执行成功则将结果封装为ResultAttempt
attempt = new Retryer.ResultAttempt<V>(result, attemptNumber, TimeUnit.NANOSECONDS.toMillis(System.nanoTime() - startTime));
} catch (Throwable t) {
// 执行异常则将结果封装为ExceptionAttempt
attempt = new Retryer.ExceptionAttempt<V>(t, attemptNumber, TimeUnit.NANOSECONDS.toMillis(System.nanoTime() - startTime));
}
// 这里将执行结果传给RetryListener做一些额外事情
for (RetryListener listener : listeners) {
listener.onRetry(attempt);
}
// 这个就是决定是否要进行重试的地方,如果不进行重试直接返回结果,执行成功就返回结果,执行失败就返回异常
if (!rejectionPredicate.apply(attempt)) {
return attempt.get();
}
// 到这里,说明需要进行重试,则此时先决定是否到达了停止重试的时机,如果到达了则直接返回异常
if (stopStrategy.shouldStop(attempt)) {
throw new RetryException(attemptNumber, attempt);
} else {
// 决定重试时间间隔
long sleepTime = waitStrategy.computeSleepTime(attempt);
try {
// 进行阻塞
blockStrategy.block(sleepTime);
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
throw new RetryException(attemptNumber, attempt);
}
}
}
}
相关推荐
- 面试怕被问Hashmap,多看看这个文章
-
o数据结构otable数组长度永远为2的幂次方o那么为什么要把数组长度设计为2的幂次方呢?o扩容o链表树化o红黑树拆分o查找o插入o删除o遍历oequasl和hashcode总结HashMap是面试中...
- 非常简洁地重试Retry组件,使用起来杠杠的
-
前言小伙伴是不是经常遇到接口调用异常,超时的场景?尤其网络抖动导致timeout超时的场景,我们一般产品就会叫我们要重试几次。很多小伙伴的实现方式是写个循环调用for(inti=1;i<=3;...
- Kafka消息可靠传输之幂等、事务机制
-
一般而言,消息中间件的消息传输保障有3个层级,分别如下。atmostonce:至多一次。消息可能会丢失,但绝对不会重复传输。atleastonce:最少一次。消息绝不会丢失,但可能会重复传输。...
- Seata源码—9.Seata XA模式的事务处理
-
大纲1.SeataXA分布式事务案例及AT与XA的区别2.SeataXA分布式事务案例的各模块运行流程3.Seata使用SpringBoot自动装配简化复杂配置4.全局事务注解扫描组件的自动装配...
- Disruptor—3.核心源码实现分析一
-
大纲1.Disruptor的生产者源码分析2.Disruptor的消费者源码分析3.Disruptor的WaitStrategy等待策略分析4.Disruptor的高性能原因5.Disruptor高性...
- Spring Boot 进阶-详解SpringBoot中条件注解使用
-
作为使用SpringBoot框架的开发者来讲,如果你连如下的这些注解你都没有听说过,没有用过,那我劝你还是放弃吧?在SpringBoot中我们最常见到的注解应该是条件注解了吧!也就是@Condit...
- 如何自定义编解码器(如何自定义编解码器的程序)
-
1.前言上一节我们一节了解了什么是编码解码、序列化和反序列化了,并且留有一道思考题,本节内容主要是深入解析该思考题。思考题:能否把我们的编码和解码封装成独立的Handler呢?那么应该如何去封装...
- Disruptor—3.核心源码实现分析二
-
大纲1.Disruptor的生产者源码分析2.Disruptor的消费者源码分析3.Disruptor的WaitStrategy等待策略分析4.Disruptor的高性能原因5.Disruptor高性...
- 线程的状态有哪些?它是如何工作的?
-
线程的状态有哪些?它是如何工作的?线程(Thread)是并发编程的基础,也是程序执行的最小单元,它依托进程而存在。一个进程中可以包含多个线程,多线程可以共享一块内存空间和一组系统资源,因此线程之间的切...
- 有图解有案例,我终于把Condition的原理讲透彻了
-
平时加解锁都是直接使用Synchronized关键字来实现的,简单好用,为啥还要引用ReentrantLock呢?为了解决小伙伴的疑问,我们来对两者做个简单的比较吧:相同点两者都是“可重入锁”,即当前...
- 白话DUBBO原理,通俗易记,再也不怕面试时讲不清楚了
-
现在的各种面试免不了要问些中间件,尤其是互联网公司,更注重获选人对中间件的掌握情况。在中间件中,有一大类是关于RPC框架的,Dubbo即是阿里出品的一款很著名的RPC中间件,很多互联网公司都在用,面试...
- Java 最细的集合类总结(java常用的集合类有哪些)
-
数据结构作为每一个开发者不可回避的问题,而Java对于不同的数据结构提供了非常成熟的实现,这一个又一个实现既是面试中的难点,也是工作中必不可少的工具,在此,笔者经历漫长的剖析,将其抽丝剥茧的呈现出...
- 详解Java异常(Exception)处理及常见异常
-
很多事件并非总是按照人们自己设计意愿顺利发展的,经常出现这样那样的异常情况。例如:你计划周末郊游,计划从家里出发→到达目的→游泳→烧烤→回家。但天有不测风云,当你准备烧烤时候突然天降大雨,只能终止郊...
- 为什么阿里强制要求不要在foreach循环里进行元素remove和add操作
-
在阅读《阿里巴巴Java开发手册》时,发现有一条关于在foreach循环里进行元素的remove/add操作的规约,具体内容如下:错误演示我们首先在IDEA中编写一个在foreach循...
- SpringBoot条件化配置(@Conditional)全面解析与实战指南
-
一、条件化配置基础概念1.1什么是条件化配置条件化配置是Spring框架提供的一种基于特定条件来决定是否注册Bean或加载配置的机制。在SpringBoot中,这一机制通过@Conditional...
- 一周热门
-
-
Python实现人事自动打卡,再也不会被批评
-
Psutil + Flask + Pyecharts + Bootstrap 开发动态可视化系统监控
-
【验证码逆向专栏】vaptcha 手势验证码逆向分析
-
一个解决支持HTML/CSS/JS网页转PDF(高质量)的终极解决方案
-
再见Swagger UI 国人开源了一款超好用的 API 文档生成框架,真香
-
网页转成pdf文件的经验分享 网页转成pdf文件的经验分享怎么弄
-
C++ std::vector 简介
-
python使用fitz模块提取pdf中的图片
-
《人人译客》如何规划你的移动电商网站(2)
-
Jupyterhub安装教程 jupyter怎么安装包
-
- 最近发表
- 标签列表
-
- python判断字典是否为空 (50)
- crontab每周一执行 (48)
- aes和des区别 (43)
- bash脚本和shell脚本的区别 (35)
- canvas库 (33)
- dataframe筛选满足条件的行 (35)
- gitlab日志 (33)
- lua xpcall (36)
- blob转json (33)
- python判断是否在列表中 (34)
- python html转pdf (36)
- 安装指定版本npm (37)
- idea搜索jar包内容 (33)
- css鼠标悬停出现隐藏的文字 (34)
- linux nacos启动命令 (33)
- gitlab 日志 (36)
- adb pull (37)
- table.render (33)
- uniapp textarea (33)
- python判断元素在不在列表里 (34)
- python 字典删除元素 (34)
- vscode切换git分支 (35)
- python bytes转16进制 (35)
- grep前后几行 (34)
- hashmap转list (35)