扒一扒@Retryable注解,很优雅,有点意思

你好呀,我是动作缓慢的程序猿

可关注公众号 :动作缓慢的程序猿    领取最新大厂面试题

前几天我 Review 代码的时候发现项目里面有一坨逻辑写的非常的不好,一眼望去简直就是丑陋之极。

我都不知道为什么会有这样的代码存在项目里面,于是我看了一眼提交记录准备叫对应的同事问问,为什么会写出这样的代码。

然后...

那一坨代码是我 2019 年的时候提交的。

我细细的思考了一下,当时好像由于对项目不熟悉,然后其他的项目里面又有一个类似的功能,我就直接 CV 大法搞过来了,里面的逻辑也没细看。

嗯,原来是历史原因,可以理解,可以理解。

代码里面主要就是一大坨重试的逻辑,各种硬编码,各种辣眼睛的补丁。

特别是针对重试的逻辑,到处都有。所以我决定用一个重试组件优化一波。

今天就带大家卷一下 Spring-retry 这个组件。

 

丑陋的代码

先简单的说一下丑陋的代码大概长什么样子吧。

给你一个场景,假设你负责支付服务,需要对接外部的一个渠道,调用他们的订单查询接口。

他们给你说:由于网络问题,如果我们之间交互超时了,你没有收到我的任何响应,那么按照约定你可以对这个接口发起三次重试,三次之后还是没有响应,那就应该是有问题了,你们按照异常流程处理就行。

假设你不知道 Spring-retry 这个组件,那么你大概率会写出这样的代码:

逻辑很简单嘛,就是搞个 for 循环,然后异常了就发起重试,并对重试次数进行检查。

然后搞个接口来调用一下:

 发起调用之后,日志的输出是这样的,一目了然,非常清晰:

 

正常调用一次,重试三次,一共可以调用 4 次。在第五次调用的时候抛出异常。

完全符合需求,自测也完成了,可以直接提交代码,交给测试同学了。

非常完美,但是你有没有想过,这样的代码其实非常的不优雅。

你想,如果再来几个类似的“超时之后可以发起几次重试”需求。

那你这个 for 循环是不是得到处的搬来搬去。就像是这样似的,丑陋不堪:

 实话实说,我以前也写过这样的丑代码。

 

但是我现在是一个有代码洁癖的人,这样的代码肯定是不能忍的。

重试应该是一个工具类一样的通用方法,是可以抽离出来的,剥离到业务代码之外,开发的时候我们只需要关注业务代码写的巴巴适适就行了。

那么怎么抽离呢?

你说巧不巧,我今天给你分享这个的东西,就把重试功能抽离的非常的好:

 用上 spring-retry 之后,我们上面的代码就变成了这样:

只是加上了一个 @Retryable 注解,这玩意简直简单到令人发指。

一眼望去,非常的优雅!

所以,我决定带大家扒一扒这个注解。看看别人是怎么把“重试”这个功能抽离成一个组件的,这比写业务代码有意思。

我这篇文章不会教大家怎么去使用 spring-retry,它的功能非常的丰富,写用法的文章已经非常多了。我想写的是,当我会使用它之后,我是怎么通过源码的方式去了解它的。

怎么把它从一个只会用的东西,变成简历上的那一句:翻阅过相关源码。

 

可添加公众号领取免费大厂面试资料:动作缓慢的程序猿

但是你要压根都不会用,都没听过这个组件怎么办呢?

没关系,我了解一个技术点的第一步,一定是先搭建出一个非常简单的 Demo。

没有跑过 Demo 的一律当做一无所知处理。

先搭 Demo

我最开始也是对这个注解一无所知的。

所以,对于这种情况,废话少说,先搞个 Demo 跑起来才是王道。

但是你记住搭建 Demo 也是有技巧的:直接去官网或者 github 上找就行了,那里面有最权威的、最简洁的 Demo。

比如 spring-retry 的 github 上的 Quick Start 就非常简洁易懂。

它分别提供了注解式开发和编程式开发的示例。

我们这里主要看它的注解式开发案例:

里面涉及到三个注解:

  • @EnableRetry:加在启动类上,表示支持重试功能。

  • @Retryable:加在方法上,就会给这个方法赋能,让它有用重试的功能。

  • @Recover:重试完成后还是不成功的情况下,会执行被这个注解修饰的方法。

看完 git 上的 Quick Start 之后,我很快就搭了一个 Demo 出来。

如果你之前不了解这个组件的使用方法的话,我强烈建议你也搭一个,非常的简单。

首先是引入 maven 依赖:

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

由于该组件是依赖于 AOP 给你的,所以还需要引入这个依赖:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-aop</artifactId>
    <version>2.6.1</version>
</dependency>

然后是代码,就这么一点,就够够的了:

 

 最后把项目跑起来,调用一笔,确实是生效了,执行了 @Recover 修饰的方法:

<

  • 4
    点赞
  • 8
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
Spring @Retryable注解是一种在Spring框架中实现重试机制的解决方案。这个解决方案的主要思想是在方法发生异常时,让这个方法重新执行一次或多次,直到方法成功执行为止。这个方案可以让开发者在开发过程中减少一定的错误处理代码的编写,同时还可以增加系统的可靠性和鲁棒性。 使用Spring @Retryable注解的方法必须满足一定的条件,首先他必须存在于一个Spring管理的Bean中,其次必须有异常抛出。@Retryable注解可以指定重试的次数,每次重试间隔时间,重试的异常条件等等。这些参数可以根据开发者的需要进行深度定制,以实现更加灵活的重试行为。 @Retryable注解的处理方式是在Spring框架中通过AOP(面向切面编程)来进行的。具体的实现方式是,在AOP中拦截所有的方法调用,当被拦截的方法抛出指定的异常时,AOP会将这个异常交给重试拦截器进行处理,在处理过程中,重试拦截器会根据开发者指定的参数进行重试操作,并在重试次数达到上限后将异常抛回给方法调用者。 总的来说,Spring @Retryable注解提供了一种简单有效的处理异常情况的解决方案。在实际开发过程中,经常会遇到一些类似网络延迟、数据库访问失败等问题,这些问题往往需要程序员进行手动处理,而使用@Retryable注解可以让我们简化这种操作,提高程序的鲁棒性和可靠性。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值