ribbon的重试机制

1.在调用端的pom.xml加入重试jar

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

2.修改yml文件

service-product:
  ribbon:
    ConnectTimeout: 250 # Ribbon的连接超时时间
    ReadTimeout: 1000 # Ribbon的数据读取超时时间
    OkToRetryOnAllOperations: true # 是否对所有操作都进行重试
    MaxAutoRetriesNextServer: 1 # 切换实例的重试次数
    MaxAutoRetries: 1 # 对当前实例的重试次数
logging:
  level:
    root: debug

3.关闭一个服务，开始调用，然后查看日志

2020-02-05 15:31:29.914 DEBUG 24644 --- [nio-9012-exec-4] o.s.web.client.RestTemplate              : HTTP GET http://service-product/product/1
2020-02-05 15:31:29.914 DEBUG 24644 --- [nio-9012-exec-4] o.s.web.client.RestTemplate              : Accept=[application/json, application/*+json]
2020-02-05 15:31:29.914 DEBUG 24644 --- [nio-9012-exec-4] c.n.loadbalancer.ZoneAwareLoadBalancer   : Zone aware logic disabled or there is only one zone
2020-02-05 15:31:29.915 DEBUG 24644 --- [nio-9012-exec-4] o.s.retry.support.RetryTemplate          : Retry: count=0
2020-02-05 15:31:29.915 DEBUG 24644 --- [nio-9012-exec-4] s.n.www.protocol.http.HttpURLConnection  : [email protected] pairs: {GET /product/1 HTTP/1.1: null}{Accept: application/json, application/*+json}{User-Agent: Java/1.8.0_121}{Host: 10.9.9.139:9011}{Connection: keep-alive}
2020-02-05 15:31:31.920 DEBUG 24644 --- [nio-9012-exec-4] o.s.c.n.r.RibbonLoadBalancedRetryPolicy  : 10.9.9.139:9011 RetryCount: 1 Successive Failures: 2 CircuitBreakerTripped:false
2020-02-05 15:31:31.920 DEBUG 24644 --- [nio-9012-exec-4] o.s.retry.support.RetryTemplate          : Checking for rethrow: count=1
2020-02-05 15:31:31.920 DEBUG 24644 --- [nio-9012-exec-4] o.s.retry.support.RetryTemplate          : Retry: count=1
2020-02-05 15:31:33.923 DEBUG 24644 --- [nio-9012-exec-4] o.s.c.n.r.RibbonLoadBalancedRetryPolicy  : 10.9.9.139:9011 RetryCount: 2 Successive Failures: 4 CircuitBreakerTripped:true
2020-02-05 15:31:33.923 DEBUG 24644 --- [nio-9012-exec-4] c.n.loadbalancer.ZoneAwareLoadBalancer   : Zone aware logic disabled or there is only one zone
2020-02-05 15:31:33.923 DEBUG 24644 --- [nio-9012-exec-4] o.s.retry.support.RetryTemplate          : Checking for rethrow: count=2
2020-02-05 15:31:33.923 DEBUG 24644 --- [nio-9012-exec-4] o.s.retry.support.RetryTemplate          : Retry: count=2
2020-02-05 15:31:33.924 DEBUG 24644 --- [nio-9012-exec-4] s.n.www.protocol.http.HttpURLConnection  : [email protected] pairs: {GET /product/1 HTTP/1.1: null}{Accept: application/json, application/*+json}{User-Agent: Java/1.8.0_121}{Host: 10.9.9.139:9001}{Connection: keep-alive}
2020-02-05 15:31:33.932 DEBUG 24644 --- [nio-9012-exec-4] s.n.www.protocol.http.HttpURLConnection  : [email protected] pairs: {null: HTTP/1.1 200}{Content-Type: application/json;charset=UTF-8}{Transfer-Encoding: chunked}{Date: Wed, 05 Feb 2020 07:31:33 GMT}{Keep-Alive: timeout=60}{Connection: keep-alive}
2020-02-05 15:31:33.932 DEBUG 24644 --- [nio-9012-exec-4] o.s.web.client.RestTemplate              : Response 200 OK
2020-02-05 15:31:33.932 DEBUG 24644 --- [nio-9012-exec-4] o.s.web.client.RestTemplate              : Reading to [com.topcheer.order.entity.Product]
2020-02-05 15:31:33.933 DEBUG 24644 --- [nio-9012-exec-4] m.m.a.RequestResponseBodyMethodProcessor : Using ‘application/json;q=0.8‘, given [text/html, application/xhtml+xml, image/webp, image/apng, application/signed-exchange;v=b3, application/xml;q=0.9, */*;q=0.8] and supported [application/json, application/*+json, application/json, application/*+json]
2020-02-05 15:31:33.933 DEBUG 24644 --- [nio-9012-exec-4] m.m.a.RequestResponseBodyMethodProcessor : Writing [Product(id=1, productName=访问的服务地址:10.9.9.139:9001, status=1, price=1000.00, productDesc=抗曹, caption= (truncated)...]
2020-02-05 15:31:33.934 DEBUG 24644 --- [nio-9012-exec-4] o.j.s.OpenEntityManagerInViewInterceptor : Closing JPA EntityManager in OpenEntityManagerInViewInterceptor
2020-02-05 15:31:33.934 DEBUG 24644 --- [nio-9012-exec-4] o.s.web.servlet.DispatcherServlet        : Completed 200 OK

发现在尝试一次以后，又切换到9001了，不过ribbon用的不多，用的都是feign。

原文地址：https://www.cnblogs.com/dalianpai/p/12264051.html

时间： 2024-08-30 16:25:30

ribbon的重试机制的相关文章

SpringCloud | FeignClient和Ribbon重试机制区别与联系

在spring cloud体系项目中,引入的重试机制保证了高可用的同时,也会带来一些其它的问题,如幂等操作或一些没必要的重试. 今天就来分别分析一下 FeignClient 和 Ribbon 重试机制的实现原理和区别,主要分为三点: 1)FeignClient重试机制分析 2)Ribbon重试机制分析 3)FeignClient和Ribbon重试机制的区别于联系 1)FeignClient 重试机制分析: FeignClient 重试机制的实现原理相对简单.首先看一下feignClient处理请

一文详解Spring Cloud Feign重试机制

前言 Feign组件默认使用Ribbon的重试机制并增加了根据状态码判断重试机制,默认情况下是不启用的.Feign使用的是Spring Retry组件,需要引入依赖才能启用. 一.POM引入Spring Retry <dependency> <groupId>org.springframework.retry</groupId> <artifactId>spring-retry</artifactId> </dependency> 二

Volley超时重试机制详解

Volley超时重试机制基础用法 Volley为开发者提供了可配置的超时重试机制,我们在使用时只需要为我们的Request设置自定义的RetryPolicy即可. 参考设置代码如下: int DEFAULT_TIMEOUT_MS = 10000; int DEFAULT_MAX_RETRIES = 3; StringRequest stringRequest = new StringRequest(Request.Method.GET, url, new Response.Listener<S

Rocket重试机制，消息模式，刷盘方式

一.Consumer 批量消费(推模式) 可以通过 consumer.setConsumeMessageBatchMaxSize(10);//每次拉取10条这里需要分为2种情况 Consumer端先启动 Consumer端后启动. 正常情况下:应该是Consumer需要先启动注意:如果broker采用推模式的话,consumer先启动,会一条一条消息的消费,consumer后启动会才用批量消费 Consumer端先启动 1.Consumer.java package quickstart

jedis超时重试机制注意事项

最近使用redis集群进行incr操作,总是发现计数不准确,后来经过检查发现redis在执行incr超时会执行重试机制,造成计数不准确,测试代码: /** * incrf: * 将 key 中储存的数字值增一. 如果 key 不存在,那么 key 的值会先被初始化为 0 ,然后再执行 INCR 操作. 如果值包含错误的类型,或字符串类型的值不能表示为数字,那么返回一个错误. 本操作的值限制在 64 位(bit)有符号数字表示之内. 这是一个针对字符串的操作,因为 Redis 没有专用的整数类型,

为你的代码加上一层重试机制

为代码加上重试机制 1.前言:对于经常跟网络编程打交道的你来说,并不是你的每次Request,Server都会给你想要的Response.重试机制虽然并不能解决这种情况,但是却可以大大减少这种情况的发生. 2.介绍下重试机制类:RetryUtil.cs 使用了委托,代码很短,也不难理解. 1 public class RetryUtil 2 { 3 public delegate void NoArgumentHandler(); 4 /// <summary> 5 /// retry mec

guava的重试机制guava-retrying使用

1,添加maven依赖 <dependency> <groupId>com.github.rholder</groupId> <artifactId>guava-retrying</artifactId> <version>2.0.0</version> </dependency> 2,定义重试机制 Retryer<CMSResultDTO> smsRetryer = RetryerBuilder.

PHP-RESQUE重试机制

因为PHP-Resque 的重试需要自己写,网上又没啥轮子,而且resque也很久不更新了,所以自己研究下resque的源码,然后也借鉴了Laravel的队列重试机制,实现了PHP-Resque的重试机制. 设计思路阅读resque源码,我们知道,resque把失败的队列的数据都放在了resque:failed列表,数据如下. 我的项目是在yii2下统一处理resque的,我直接resque源码在新增了retry方法,在每一个failJob的payload增加了attempts尝试次数,一开始

feginclient和ribbon的重试策略

//自定义重试次数// @Bean// public Retryer feignRetryer(){// Retryer retryer = new Retryer.Default(100, 1000, 2);// return retryer;// } 如果设置了feginclient的重试次数(2次),那么fegin将会使用轮训的方式重试nextServer. 如果要使用ribbon作为重试,要把feginclient的超时时间配置和重试配置去掉.ribbon: MaxAutoRetries