ribbon和hytrix超时踩坑记录

在学习商城项目时，接触到了搜索，完了以后我看着这搜索时灵时不灵根本没办法实际使用，看着控制台报着zuul和hytrix的错误和警告，陷入了深思…

主要是涉及以下几个错误和警告

ribbon超时时间设置太短，报如下错误

com.netflix.zuul.exception.ZuulException: 
	at org.springframework.cloud.netflix.zuul.filters.post.SendErrorFilter.findZuulException(SendErrorFilter.java:114) ~[spring-cloud-netflix-zuul-2.0.2.RELEASE.jar:2.0.2.RELEASE]
	at org.springframework.cloud.netflix.zuul.filters.post.SendErrorFilter.run(SendErrorFilter.java:76) ~[spring-cloud-netflix-zuul-2.0.2.RELEASE.jar:2.0.2.RELEASE]
	at com.netflix.zuul.ZuulFilter.runFilter(ZuulFilter.java:117) [zuul-core-1.3.1.jar:1.3.1]
	at com.netflix.zuul.FilterProcessor.processZuulFilter(FilterProcessor.java:193) [zuul-core-1.3.1.jar:1.3.1]
	at com.netflix.zuul.FilterProcessor.runFilters(FilterProcessor.java:157) [zuul-core-1.3.1.jar:1.3.1]
	...

原因：通过源码可以看到ribbon的默认超时时间是1s，毕竟还是要查找数据库的，时间摆在那里，服务器性能又不是很好，不设置或者设置的时间太短的话就容易出现这个问题了

解决方案

zuul网关那个yml设置一下ribbon超时时间，这里我设置成了30000

1
2
3

ribbon:
  ReadTimeout: 30000
  ConnectTimeout: 30000

也不是越长越好，如果真的发生了错误，一直在等，如果这时候用户再发送其他请求，容易出现如下错误

1	你的主机中的软件中止了一个已建立的连接

综上，考虑到服务器的性能（这里是笔记本）和数据量（这里是千），我个人认为30000-40000是比较合理的，甚至可以再大一点

还有一个是hytrix超时时间，如果没有设置好（太短或者小于ribbon总超时时间），造成查询特别慢，甚至触发了hytrix的熔断机制，这个问题比较普遍，网上也有一堆的解决办法，这个警告是这样的

1	The Hystrix timeout of 60000ms for the command search-service is set lower than the combination of the Ribbon read and connect timeout, 120000ms.

意思是hytrix超时时间大于了ribbon超时时间，可是我们ribbon设置的明明就是30000呀，这个120000是什么？其实这个120000是读写总时间，具体计算方式是(30000+30000)*(0+1)*(1+1)=120000

我们可以在源码中看到

因此，我们应该把hytrix的超时时间设置成大于这个值

综上所述，我最终的yml配置如下

ribbon:
  ReadTimeout: 30000
  ConnectTimeout: 30000
hystrix:
  command:
    default:
      execution:
        isolation:
          thread:
            timeoutInMilliseconds: 120000 # 设置hystrix的超时时间为120000ms

感谢这两篇博客的指导

https://blog.csdn.net/a405828/article/details/107302984

https://blog.csdn.net/lidew521/article/details/84661158

# springcloud, 开发

文章

102

分类

14

标签

26

关注我

ribbon和hytrix超时踩坑记录

分类

标签云

推荐阅读

推荐阅读

Your browser is out-of-date!