详解重试框架Spring retry实践

spring retry是从spring batch独立出来的一个能功能,主要实现了重试和熔断。对于重试是有场景限制的,不是什么场景都适合重试,比如参数校验不合法、写操作等(要考虑写是否幂等)都不适合重试。远程调用超时、网络突然中断可以重试。在微服务治理框架中,通常都有自己的重试与超时配置,比如dubbo可以设置retries=1,timeout=500调用失败只重试1次,超过500ms调用仍未返回则调用失败。在spring retry中可以指定需要重试的异常类型,并设置每次重试的间隔以及如果重试失败是继续重试还是熔断(停止重试)。

设计与实现

RetryOperations定义重试的API,RetryTemplate是API的模板模式实现,实现了重试和熔断。提供的API如下:

public interface RetryOperations {
  <T, E extends Throwable>T execute(RetryCallback<T, E>retryCallback) throws E;
  }
  // 其他API已省略

RetryCallback定义了需要执行重试的操作,定义好操作后,就是如何重试的问题了。RetryTemplate通过制定不同的重试策略来执行如何重试的逻辑。默认的重试策略是SimpleRetryPlicy,也就是会重试3次。重试第1次如果成功后面就不会继续重试了。那么如果3尺都重试失败了呢?流程结束或者返回兜底结果。要返回兜底结果需要配置RecoveyCallBack,从名字可以看出这是一个兜底回调接口,也就是重试失败后执行的逻辑。除了SimpleRetryPolicy还有其他重试策略,先来看下RetryPolicy接口:

public interface RetryPolicy extends Serializable {
  boolean canRetry(RetryContext context);
  RetryContext open(RetryContext parent);
  void close(RetryContext context);
  void registerThrowable(RetryContext context, Throwable throwable);
}

canRetry在每次重试的时候调用,是否可以继续重试的判断条件
open重试开始前调用,会创建一个重试上下文到RetryContext,保存重试的堆栈等信息
registerThrowable每次重试异常时调用(有异常会继续重试)

SimpleRetryPolicy为例,当重试次数达到3(默认3次)停止重试,重试次数保存在重试上下文中。

提供如下重试策略实现:

  1. NeverRetryPolicy:只允许调用RetryCallback一次,不允许重试
  2. AlwaysRetryPolicy:允许无限重试,直到成功,此方式逻辑不当会导致死循环
  3. SimpleRetryPolicy:固定次数重试策略,默认重试最大次数为3次,RetryTemplate默认使用的策略
  4. TimeoutRetryPolicy:超时时间重试策略,默认超时时间为1秒,在指定的超时时间内允许重试
  5. ExceptionClassifierRetryPolicy:设置不同异常的重试策略,类似组合重试策略,区别在于这里只区分不同异常的重试
  6. CircuitBreakerRetryPolicy:有熔断功能的重试策略,需设置3个参数openTimeout、resetTimeout和delegate
  7. CompositeRetryPolicy:组合重试策略,有两种组合方式,乐观组合重试策略是指只要有一个策略允许重试即可以,悲观组合重试策略是指只要有一个策略不允许重试即可以,但不管哪种组合方式,组合中的每一个策略都会执行

重试回退策略,指的是每次重试是立即重试还是等待一段时间后重试。默认情况下是立即重试,如果需要配置等待一段时间后重试则需要指定回退策略BackoffRetryPolicy。BackoffRetryPolicy有如下实现:

  1. NoBackOffPolicy:无退避算法策略,每次重试时立即重试
  2. FixedBackOffPolicy:固定时间的退避策略,需设置参数sleeper和backOffPeriod,sleeper指定等待策略,默认是Thread.sleep,即线程休眠,backOffPeriod指定休眠时间,默认1秒
  3. UniformRandomBackOffPolicy:随机时间退避策略,需设置sleeper、minBackOffPeriod和maxBackOffPeriod,该策略在[minBackOffPeriod,maxBackOffPeriod之间取一个随机休眠时间,minBackOffPeriod默认500毫秒,maxBackOffPeriod默认1500毫秒
  4. ExponentialBackOffPolicy:指数退避策略,需设置参数sleeper、initialInterval、maxInterval和multiplier,initialInterval指定初始休眠时间,默认100毫秒,maxInterval指定最大休眠时间,默认30秒,multiplier指定乘数,即下一次休眠时间为当前休眠时间*multiplier
  5. ExponentialRandomBackOffPolicy:随机指数退避策略,引入随机乘数可以实现随机乘数回退

有状态重试 OR 无状态重试

所谓无状态重试是指重试在一个线程上下文中完成的重试,反之不在一个线程上下文完成重试的就是有状态重试。之前的SimpleRetryPolicy就属于无状态重试,因为重试是在一个循环中完成的。那么什么会后会出现或者说需要有状态重试呢?通常有两种情况:事务回滚和熔断。

数据库操作异常DataAccessException,不能执行重试,而如果抛出其他异常可以重试。

熔断的意思不在当前循环中处理重试,而是全局重试模式(不是线程上下文)。熔断会跳出循环,那么必然会丢失线程上下文的堆栈信息。那么肯定需要一种“全局模式”保存这种信息,目前的实现放在一个cache(map实现的)中,下次从缓存中获取就能继续重试了。

Quick Start

在需要执行重试的类上使用@EnableRetry,如果设置了proxyTargetClass=true这使用CGLIB动态代理:

@Configuration
@EnableRetry(proxyTargetClass = true)
@Component
public class RetryExamples {

}

基于最大重试次数策略的重试,如果重试了3次仍然抛出异常则停止重试,执行兜底回调,所以最后的输出结果是Integer.MAX_VALUE

private void retryExample3() throws Exception {
    RetryTemplate retryTemplate = new RetryTemplate();

    SimpleRetryPolicy simpleRetryPolicy = new SimpleRetryPolicy();
    simpleRetryPolicy.setMaxAttempts(3);

    retryTemplate.setRetryPolicy(simpleRetryPolicy);

    Integer result = retryTemplate.execute(new RetryCallback<Integer, Exception>() {
      int i = 0;

       // 重试操作
      @Override
      public Integer doWithRetry(RetryContext retryContext) throws Exception {
        log.info("retry count: {}", retryContext.getRetryCount());
        return len(i++);
      }
    }, new RecoveryCallback<Integer>() { //兜底回调
      @Override
      public Integer recover(RetryContext retryContext) throws Exception {
        log.info("after retry: {}, recovery method called!", retryContext.getRetryCount());
        return Integer.MAX_VALUE;
      }
    });
    log.info("final result: {}", result);
  }

  private int len(int i) throws Exception {
    if (i < 10) throw new Exception(i + " le 10");
    return i;
  }

下面介绍如何使用熔断重试策略模式(CircuitBreakerRetryPolicy),需要设置如下三个参数:

  1. delegate:传入RetryPolicy(每个RetryPolicy实现都有自己的重试策略实现),是真正判断是否重试的策略,当重试失败时,则执行熔断策略
  2. openTimeout:openWindow,配置熔断器电路打开的超时时间,当超过openTimeout之后熔断器电路变成半打开状态(只要有一次重试成功,则闭合电路)
  3. resetTimeout:timeout,配置重置熔断器重新闭合的超时时间

断路器开闭实现判断:

  1. 当重试失败,且在熔断器打开时间窗口[0,openWindow) 内,立即熔断
  2. 当重试失败,且超过timeout,熔断器电路重新闭合
  3. 在熔断器半打开状态[openWindow, timeout] 时,只要重试成功则重置上下文,断路器闭合

测试代码如下:

RetryTemplate template = new RetryTemplate();
    CircuitBreakerRetryPolicy retryPolicy =
        new CircuitBreakerRetryPolicy(new SimpleRetryPolicy(3));
    retryPolicy.setOpenTimeout(5000);
    retryPolicy.setResetTimeout(20000);
    template.setRetryPolicy(retryPolicy);

    for (int i = 0; i < 10; i++) {
      //Thread.sleep(100);
      try {
        Object key = "circuit";
        boolean isForceRefresh = false;
        RetryState state = new DefaultRetryState(key, isForceRefresh);
        String result = template.execute(new RetryCallback<String, RuntimeException>() {
          @Override
          public String doWithRetry(RetryContext context) throws RuntimeException {
            log.info("retry count: {}", context.getRetryCount());
            throw new RuntimeException("timeout");
          }
        }, new RecoveryCallback<String>() {
          @Override
          public String recover(RetryContext context) throws Exception {
            return "default";
          }
        }, state);
        log.info("result: {}", result);
      } catch (Exception e) {
        System.out.println(e);
      }
    }

这里由于设置了isForceRefresh = false,则key = "circuit"的值(也就是RetryContext)会从缓存中获取,所以当重试失败且满足this.time < this.openWindow发生熔断的时候,后面仍然可以继续已全局模式实现重试(拿到的RetryContext是同一个)。

注解开发

如果每次有重试需求的时候都写一个RetryTemplate太臃肿了,使用注解可以大大简化开发,减少重复代码。下面是一个使用注解实现的最大重试策略的重试:

@Retryable(value = SQLDataException.class, backoff = @Backoff(value = 0L))
  public String service3() throws SQLDataException {
    log.info("service3 open");
    throw new SQLDataException();
  }

  @Recover
  public String recover(SQLDataException ne) {
    return "SQLDataException recover";
  }

注解包括:

@EnableRetry

@Retryable

@Recover

@Backoff

@CircuitBreaker

@EnableRetry:能否重试,proxyTargetClass属性为true时(默认false),使用CGLIB代理

@Retryable:注解需要被重试的方法

  1. include 指定处理的异常类。默认为空
  2. exclude指定不需要处理的异常。默认为空
  3. vaue指定要重试的异常。默认为空
  4. maxAttempts 最大重试次数。默认3次
  5. backoff 重试等待策略。默认使用@Backoff注解

@Backoff:重试回退策略(立即重试还是等待一会再重试)

  1. 不设置参数时,默认使用FixedBackOffPolicy,重试等待1000ms
  2. 只设置delay()属性时,使用FixedBackOffPolicy,重试等待指定的毫秒数
  3. 当设置delay()和maxDealy()属性时,重试等待在这两个值之间均态分布
  4. 使用delay(),maxDealy()和multiplier()属性时,使用ExponentialBackOffPolicy
  5. 当设置multiplier()属性不等于0时,同时也设置了random()属性时,使用ExponentialRandomBackOffPolicy

@Recover: 用于方法。用于@Retryable失败时的“兜底”处理方法。 @Recover注释的方法必须要与@Retryable注解的方法“签名”保持一致,第一入参为要重试的异常,其他参数与@Retryable保持一致,返回值也要一样,否则无法执行!

@CircuitBreaker:用于方法,实现熔断模式。

  1. include 指定处理的异常类。默认为空
  2. exclude指定不需要处理的异常。默认为空
  3. vaue指定要重试的异常。默认为空
  4. maxAttempts 最大重试次数。默认3次
  5. openTimeout 配置熔断器打开的超时时间,默认5s,当超过openTimeout之后熔断器电路变成半打开状态(只要有一次重试成功,则闭合电路)
  6. resetTimeout 配置熔断器重新闭合的超时时间,默认20s,超过这个时间断路器关闭

更多的例子欢迎到我的Github(https://github.com/happyxiaofan/springboot-learning-example) star。谢谢

以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持我们。

(0)

相关推荐

  • 详解Spring Retry实现原理

    在前面这篇博客中介绍了Spring Retry的使用,本文通过一个简单的例子演示Spring Retry的实现原理,例子中定义的注解只包含重试次数属性,实际上Spring Retry中注解可设置属性要多的多,单纯为了讲解原理,所以弄简单点,关于Spring Retry可查阅相关文档.博客. 注解定义 package retry.annotation; import java.lang.annotation.*; /** * Created by Jack.wu on 2016/9/30. */

  • Spring重试支持Spring Retry的方法

    本文介绍了Spring重试支持Spring Retry的方法,分享给大家,具体如下: 第一步.引入maven依赖 <parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>1.5.3.RELEASE</version> </parent> &l

  • 详解spring boot使用@Retryable来进行重处理

    前言 什么时候需要重处理? 在实际工作中,重处理是一个非常常见的场景,比如:发送消息失败,调用远程服务失败,争抢锁失败,等等,这些错误可能是因为网络波动造成的,等待过后重处理就能成功.通常来说,会用try/catch,while循环之类的语法来进行重处理,但是这样的做法缺乏统一性,并且不是很方便,要多写很多代码.然而spring-retry却可以通过注解,在不入侵原有业务逻辑代码的方式下,优雅的实现重处理功能. 思路 使用@Retryable和@Recover实现重处理,以及重处理失后的回调 实

  • spring-retry简单使用方法

    在分布式系统中,为了保证数据分布式事务的强一致性,大家在调用RPC接口或者发送MQ时,针对可能会出现网络抖动请求超时情况采取一下重试操作.大家用的最多的重试方式就是MQ了,但是如果你的项目中没有引入MQ,那就不方便了,本文主要介绍一下如何使用Spring Retry实现重试操作. 1. 添加maven依赖 <dependency> <groupId>org.springframework.retry</groupId> <artifactId>spring-

  • 详解重试框架Spring retry实践

    spring retry是从spring batch独立出来的一个能功能,主要实现了重试和熔断.对于重试是有场景限制的,不是什么场景都适合重试,比如参数校验不合法.写操作等(要考虑写是否幂等)都不适合重试.远程调用超时.网络突然中断可以重试.在微服务治理框架中,通常都有自己的重试与超时配置,比如dubbo可以设置retries=1,timeout=500调用失败只重试1次,超过500ms调用仍未返回则调用失败.在spring retry中可以指定需要重试的异常类型,并设置每次重试的间隔以及如果重

  • Spring的异常重试框架Spring Retry简单配置操作

    相关api见:点击进入 /* * Copyright 2014 the original author or authors. * * Licensed under the Apache License, Version 2.0 (the "License"); * you may not use this file except in compliance with the License. * You may obtain a copy of the License at * *

  • 详解JSP 中Spring工作原理及其作用

    详解JSP 中Spring工作原理及其作用 1.springmvc请所有的请求都提交给DispatcherServlet,它会委托应用系统的其他模块负责负责对请求进行真正的处理工作. 2.DispatcherServlet查询一个或多个HandlerMapping,找到处理请求的Controller. 3.DispatcherServlet请请求提交到目标Controller 4.Controller进行业务逻辑处理后,会返回一个ModelAndView 5.Dispathcher查询一个或多个

  • 详解Golang语言HTTP客户端实践

    目录 HTTP客户端封装 测试脚本 测试服务 最近在学习Golang语言,中间遇到一个前辈指点,有一个学习原则:Learning By Doing.跟我之前学习Java的经验高度契合.在前一段时间学习洼坑中挣扎了好几天,差点就忘记这个重要的成功经验. 那么那什么来做练习呢?当然结合当下的工作啦,所以我列了一个路线给自己,那就是从接口测试开始学起来,从功能测试到性能测试,然后掌握基本Server开发技能. 首先,得先把HTTP接口测试常用的几个功能实现了,主要是获取HTTPrequest对象,发送

  • 详解java 中Spring jsonp 跨域请求的实例

    详解java 中Spring jsonp 跨域请求的实例 jsonp介绍 JSONP(JSON with Padding)是JSON的一种"使用模式",可用于解决主流浏览器的跨域数据访问的问题.由于同源策略,一般来说位于 server1.example.com 的网页无法与不是 server1.example.com的服务器沟通,而 HTML 的<script> 元素是一个例外.利用 <script> 元素的这个开放策略,网页可以得到从其他来源动态产生的 JSO

  • 详解SSM框架下结合log4j、slf4j打印日志

    本文主要介绍了详解SSM框架下结合log4j.slf4j打印日志,分享给大家,具体如下: 首先加入log4j和slf4j的jar包 <!-- 日志处理 <!-- slf4j日志包--> <dependency> <groupId>org.slf4j</groupId> <artifactId>slf4j-api</artifactId> <version>1.7.21</version> </dep

  • 详解Yaf框架PHPUnit集成测试方法

    本文介绍了详解Yaf框架PHPUnit集成测试方法,分享给大家,具体如下: 测试目录 test ├── TestCase.php ├── bootstrap.php ├── controller │ ├── BaseControllerTest.php │ └── IndexControllerTest.php ├── model ├── phpunit.xml └── service └── TokenServiceTest.php phpunit.xml <?xml version="

  • 一文快速详解前端框架 Vue 最强大的功能

    组件是 vue.js最强大的功能之一,而组件实例的作用域是相互独立的,这就意味着不同组件之间的数据无法相互引用.一般来说,组件可以有以下几种关系: 如上图所示,A 和 B.B 和 C.B 和 D 都是父子关系,C 和 D 是兄弟关系,A 和 C 是隔代关系(可能隔多代). 针对不同的使用场景,如何选择行之有效的通信方式?这是我们所要探讨的主题.本文总结了vue组件间通信的几种方式,如props. $emit/ $on.vuex. $parent / $children. $attrs/ $lis

  • 详解Vue Cli浏览器兼容性实践

    浏览器市场占有率 在处理浏览器兼容性问题之前,我们先来看一下现在的浏览器市场份额是怎样的,

随机推荐