SpringCloud重试机制配置
首先声明一点,这里的重试并不是报错以后的重试,而是负载均衡客户端发现远程请求实例不可到达后,去重试其他实例。
@Bean @LoadBalanced RestTemplate restTemplate() { HttpComponentsClientHttpRequestFactory httpRequestFactory = new HttpComponentsClientHttpRequestFactory(); httpRequestFactory.setReadTimeout(5000); httpRequestFactory.setConnectTimeout(5000); return new RestTemplate(httpRequestFactory); }
feign重试机制
feign默认是通过自己包下的Retryer进行重试配置,默认是5次
package feign; import static java.util.concurrent.TimeUnit.SECONDS; /** * Cloned for each invocation to {@link Client#execute(Request, feign.Request.Options)}. * Implementations may keep state to determine if retry operations should continue or not. */ public interface Retryer extends Cloneable { /** * if retry is permitted, return (possibly after sleeping). Otherwise propagate the exception. */ void continueOrPropagate(RetryableException e); Retryer clone(); public static class Default implements Retryer { private final int maxAttempts; private final long period; private final long maxPeriod; int attempt; long sleptForMillis; public Default() { this(100, SECONDS.toMillis(1), 5); } public Default(long period, long maxPeriod, int maxAttempts) { this.period = period; this.maxPeriod = maxPeriod; this.maxAttempts = maxAttempts; this.attempt = 1; }
feign取消重试
@Bean Retryer feignRetryer() { return Retryer.NEVER_RETRY; }
feign请求超时设置
@Bean Request.Options requestOptions(ConfigurableEnvironment env){ int ribbonReadTimeout = env.getProperty("ribbon.ReadTimeout", int.class, 6000); int ribbonConnectionTimeout = env.getProperty("ribbon.ConnectTimeout", int.class, 3000); return new Request.Options(ribbonConnectionTimeout, ribbonReadTimeout); }
Spring Cloud中各组件的重试
最近挺多童鞋问我如何配置Spring Cloud xxx组件的重试。本篇进行一个总结。
Spring Cloud中的重试机制应该说是比较混乱的,不同的版本有一定区别,实现也不大一样,好在Spring Cloud Camden之后已经基本稳定下来,Dalston中又进行了一些改进,详情暂且不表。
下面我们来详细探讨。
笔者使用的版本是 Spring Cloud Dalston SR4 ,同样适应于Edgware 以及更高版本,对于Dalston 此前的版本,本文不做讨论,大家可自行研究。
Ribbon+RestTemplate的重试
对于整合了Ribbon的RestTemplate,例如一个RestTemplate添加了@LoadBalanced 注解:
@Bean @LoadBalanced public RestTemplate restTemplate() { SimpleClientHttpRequestFactory simpleClientHttpRequestFactory = new SimpleClientHttpRequestFactory(); simpleClientHttpRequestFactory.setConnectTimeout(1000); simpleClientHttpRequestFactory.setReadTimeout(1000); return new RestTemplate(simpleClientHttpRequestFactory); }
在此基础上,使用如下配置,即可实现重试:
spring: cloud: loadbalancer: retry: enabled: true ribbon: # 同一实例最大重试次数,不包括首次调用 MaxAutoRetries: 1 # 重试其他实例的最大重试次数,不包括首次所选的server MaxAutoRetriesNextServer: 2 # 是否所有操作都进行重试 OkToRetryOnAllOperations: false
Feign的重试
Feign本身也具备重试能力,在早期的Spring Cloud中,Feign使用的是 feign.Retryer.Default#Default() ,重试5次。但Feign整合了Ribbon,Ribbon也有重试的能力,此时,就可能会导致行为的混乱。
Spring Cloud意识到了此问题,因此做了改进,将Feign的重试改为 feign.Retryer#NEVER_RETRY ,如需使用Feign的重试,只需使用Ribbon的重试配置即可。因此,对于Camden以及以后的版本,Feign的重试可使用如下属性进行配置:
ribbon: MaxAutoRetries: 1 MaxAutoRetriesNextServer: 2 OkToRetryOnAllOperations: false
相关Issue可参考:https://github.com/spring-cloud/spring-cloud-netflix/issues/467
Zuul的重试
配置:
zuul: # 开启Zuul的重试 retryable: true ribbon: MaxAutoRetries: 1 MaxAutoRetriesNextServer: 2 OkToRetryOnAllOperations: false
上面我们使用 zuul.retryable=true 对Zuul全局开启了重试,事实上,也可对指定路由开启/关闭重试:
zuul.routes.<routename>.retryable=true
局部配置优先级更高。
基于HTTP响应码重试
clientName: ribbon: retryableStatusCodes: 404,502
注意点:
Hystrix的超时时间必须大于超时的时间,否则,一旦Hystrix超时,就没办法继续重试了。
一般来说,不建议将ribbon.OkToRetryOnAllOperations 设为true。因为一旦启用该配置,则表示重试任何操作,包括POST请求,而由于缓存了请求体,此时可能会影响服务器的资源。
总结
以上就是这篇文章的全部内容了,希望本文的内容对大家的学习或者工作具有一定的参考学习价值,如果有疑问大家可以留言交流,谢谢大家对小牛知识库的支持。
我正在使用Spring-Cloud-sleuth-stream和Spring-Cloud-starter-stream-kafka发送跨度到kafka,异常发生在连接中。SR1 192.168.1.177是我的localhost 初始化连接 重试例外 我不明白为什么,主机更改为,以及如何修复它
我是Spring的新手,尝试用一个简单的测试实现Spring重试。但是我不能让它工作,希望有人能告诉我我做错了什么。我还想知道,是否可以编写单元测试来验证Spring重试已经尝试了请求的最大重试次数?因为到目前为止,谷歌搜索似乎只能在集成测试中工作,因为它需要Spring首先设置上下文。
我有一个文件要上传(比如)。我第一次想将这个文件作为临时文件上传(比如)。然后,如果文件成功传输(完全传输),那么我需要将其重命名为其原始名称()。但是如果文件没有完全传输,那么我需要删除我最初上传的临时文件,因为我不想在服务器中保留损坏的文件。使用这个JSch库可以做到这一点吗?下面是示例代码。这段代码对实现这一点有意义吗? 示例代码:
我需要在akka演员重试机制与增加时间之间的重试和最大重试限制。为此,我尝试使用AKKA提供的BackOffSupervisor模式。问题是,从我的测试来看,后退策略和重试限制似乎不起作用。又或者问题出在测试上? 和试验方法 测试结束得太快了。在不到一秒钟的时间里,从BackoffSupervisor的配置来看,我预计至少需要50多秒。
我们决定在web应用程序中使用乐观锁定,以增加并发性,而不使用悲观锁定。 我们在web上看到的解决方案之一是使用带有注释的重试拦截器将方法标记为可重试。 问题是,我们希望对带有@Transactional注释的方法进行注释,但拦截器由于某种原因未能重试它们。(拦截器完全重试非事务性方法。) 所以: