摘要:
对于“接口/方法 重试”,相信很多小伙伴都听说过,但是在实际项目中却很少真正去实践过,在本篇文章中,Debug将给各位小伙伴介绍一种“重试”机制的实现,即Guava_Retrying,相对于传统的Spring_Retrying或者动态代理实现的重试功能而言,本文要介绍的Guava_Retrying机制使用起来将更加容易、灵活性更强!
内容:
老赵:“这个 接口/方法 调用又失败了,老李啊,你去写个重试功能吧!”。
老李:“他娘的,这接口调用咋又不行了。。。行吧,老子立马给你撸一个重试功能” 。
这样的对话,相信有些小伙伴会感觉似曾相识!特别是当自己在工位上安安静静的写代码时,会突然性的接到技术老大分配给自己的这种需求。。。没啥好说的,只能潜下心,去研究研究了!
对于“重试”,那可是有场景限制的,不是什么场景都适合重试,比如参数校验不合法、写操作等(因为要考虑到写是否幂等)都不适合重试。
而诸如“远程调用超时”、“网络突然中断”等业务场景则可以进行重试,在微服务 治理框架中,通常都有自己的重试与超时配置,比如Dubbo可以设置retries=1,timeout=500调用失败只重试1次,超过500ms调用仍未返回则调用失败(详情可以观看学习Debug录制的“分布式服务调度Dubbo实战教程 https://www.fightjava.com/web/index/course/detail/2 ”)
对于“外部 RPC 调用”,或者“数据入库”等操作,如果一次操作失败,则可以进行多次重试,从而提高调用成功的可能性。
下面我们基于前面搭建的SpringBoot多模块企业级项目,基于Guava_Retrying初步实现所谓的“重试功能”。工欲善其事必先利其器,首先当然是需要加入Guava_Retrying的依赖Jar,如下所示:
<!--guava-retrying-->
<dependency>
<groupId>com.github.rholder</groupId>
<artifactId>guava-retrying</artifactId>
<version>2.0.0</version>
</dependency>