#是否开启超时熔断

enabled: true

isolation:

thread:

timeoutInMilliseconds: 3000 #断路器超时时间，默认1000ms

feign.hystrix.enabled: true

2000ms 正常

4000ms 熔断

说明熔断器timeoutInMilliseconds: 3000起作用了

测试4

这里再测一个配置:

这个enable如果为false, 则表示熔断器不根据自己配置的超时时间进行熔断,这样的话就会收到ribbon的ReadTimeout配置的影响了,超过这个时间,eureka-feign会抛出timeout的异常,这个时候熔断器就会因为这个异常而进行熔断

hystrix:

command:

default:  #default全局有效，service id指定应用有效

execution:

timeout:

#是否开启超时熔断

enabled: false

测试4000ms 正常

测试6000ms 熔断. 此处是因为ribbon的ReadTimeout: 5000

3.总结

由上面的测试可以得出:

• 如果hystrix.command.default.execution.timeout.enabled为true,则会有两个执行方法超时的配置,一个就是ribbon的ReadTimeout,一个就是熔断器hystrix的timeoutInMilliseconds, 此时谁的值小谁生效

• 如果hystrix.command.default.execution.timeout.enabled为false,则熔断器不进行超时熔断,而是根据ribbon的ReadTimeout抛出的异常而熔断,也就是取决于ribbon

• ribbon的ConnectTimeout,配置的是请求服务的超时时间,除非服务找不到,或者网络原因,这个时间才会生效

• ribbon还有MaxAutoRetries对当前实例的重试次数,MaxAutoRetriesNextServer对切换实例的重试次数, 如果ribbon的ReadTimeout超时,或者ConnectTimeout连接超时,会进行重试操作

• 由于ribbon的重试机制,通常熔断的超时时间需要配置的比ReadTimeout长,ReadTimeout比ConnectTimeout长,否则还未重试,就熔断了

• 为了确保重试机制的正常运作,理论上（以实际情况为准）建议hystrix的超时时间为:(1 + MaxAutoRetries + MaxAutoRetriesNextServer) * ReadTimeout

ribbon:

OkToRetryOnAllOperations: false #对所有操作请求都进行重试,默认false

ReadTimeout: 10000   #负载均衡超时时间，默认值5000

ConnectTimeout: 2000 #ribbon请求连接的超时时间，默认值2000

MaxAutoRetries: 0     #对当前实例的重试次数，默认0

MaxAutoRetriesNextServer: 1 #对切换实例的重试次数，默认1

hystrix:

command:

default:  #default全局有效，service id指定应用有效

execution:

timeout:

enabled: true

isolation:

thread:

timeoutInMilliseconds: 20000 #断路器超时时间，默认1000ms

4.微服务优化

4.1 什么是hystrix

我们先来看这么一个图,假如订单服务需要调用积分服务,库存服务,仓储服务,订单服务的线程池有100个线程,这个时候积分服务突然挂了.这时候同时有大量的请求来访问订单服务,最终的结果是这100个线程都会卡在积分服务这里,这时候订单服务也没有多余的线程处理请求了,所以订单服务也差不多挂了.

这就是微服务中的服务雪崩问题.

而这时你会发现,如果我只是看看这个商品还有多少库存,那么订单服务就只需要调用库存服务就可以了,并不受积分服务的影响.

这个时候就是Hystrix的时刻了,Hystrix是隔离、熔断以及降级的一个框架。

Hystrix的特点,就是针对不同的服务,会搞很多个小小的线程池,比如订单服务请求库存服务是一个单独的线程池,请求积分服务是一个单独的线程池. 这样虽然积分服务的线程池全部卡住了,但是不影响库存服务的调用.

4.2 服务降级和熔断

现在库存服务的问题解决了,积分服务还没解决啊. 比如积分服务网络很差,订单服务要一直傻等积分服务响应吗?单单看一个请求,用户等个几秒可能还没什么,如果100个线程都卡住几秒,后面的请求全部得不到处理. 所以我们可以让Hystrix在一定时间后主动返回,不再等待,这就是熔断.

降级,顾名思义,就是将不重要或者不紧急的任务,延迟处理,或者暂不处理.比如上面的超时熔断,熔断了怎么办?获取不到用户的积分,直接给用户提示网络繁忙,请稍后再试,就是一种延迟处理. 比如秒杀活动,为了防止并发量太大,通常会采取限流措施,降级后的处理方案可以是：排队页面（将用户导流到排队页面等一会重试）、无货（直接告知用户没货了）、错误页（如活动太火爆了，稍后重试）。

4.3 微服务优化

了解了Hystrix的特性和超时效果,再看看下面这个图,服务A调用服务B和服务C,服务C没有太复杂的逻辑处理,300毫秒内就处理返回了,服务B逻辑复杂,Sql语句就长达上百行,经常要卡个5,6秒返回,在大量请求调用到服务B的时候,服务A调用服务B的hystrix线程池已经不堪重负,全部卡住

这里的话,首先考虑的就是服务B的优化,优化SQL,加索引,加缓存, 优化流程,同步改异步,总之缩短响应时间

一个接口，理论的最佳响应速度应该在200ms以内，或者慢点的接口就几百毫秒。

a. 如何设置Hystrix线程池大小

Hystrix线程池大小默认为10

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数Java工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Java开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录大纲截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且后续会持续更新

如果你觉得这些内容对你有帮助，可以添加V获取：vip1024b （备注Java）

写在最后

作为一名即将求职的程序员，面对一个可能跟近些年非常不同的 2019 年，你的就业机会和风口会出现在哪里？在这种新环境下，工作应该选择大厂还是小公司？已有几年工作经验的老兵，又应该如何保持和提升自身竞争力，转被动为主动？

就目前大环境来看，跳槽成功的难度比往年高很多。一个明显的感受：今年的面试，无论一面还是二面，都很考验Java程序员的技术功底。

最近我整理了一份复习用的面试题及面试高频的考点题及技术点梳理成一份“Java经典面试问题（含答案解析）.pdf和一份网上搜集的“Java程序员面试笔试真题库.pdf”（实际上比预期多花了不少精力），包含分布式架构、高可扩展、高性能、高并发、Jvm性能调优、Spring，MyBatis，Nginx源码分析，Redis，ActiveMQ、Mycat、Netty、Kafka、Mysql、Zookeeper、Tomcat、Docker、Dubbo、Nginx等多个知识点高级进阶干货！

由于篇幅有限，为了方便大家观看，这里以图片的形式给大家展示部分的目录和答案截图！

Java经典面试问题（含答案解析）

阿里巴巴技术笔试心得

一个人可以走的很快，但一群人才能走的更远。如果你从事以下工作或对以下感兴趣，欢迎戳这里加入程序员的圈子，让我们一起学习成长！

AI人工智能、Android移动开发、AIGC大模型、C C#、Go语言、Java、Linux运维、云计算、MySQL、PMP、网络安全、Python爬虫、UE5、UI设计、Unity3D、Web前端开发、产品经理、车载开发、大数据、鸿蒙、计算机网络、嵌入式物联网、软件测试、数据结构与算法、音视频开发、Flutter、IOS开发、PHP开发、.NET、安卓逆向、云计算

，欢迎戳这里加入程序员的圈子，让我们一起学习成长！**](https://bbs.csdn.net/forums/4304bb5a486d4c3ab8389e65ecb71ac0)

AI人工智能、Android移动开发、AIGC大模型、C C#、Go语言、Java、Linux运维、云计算、MySQL、PMP、网络安全、Python爬虫、UE5、UI设计、Unity3D、Web前端开发、产品经理、车载开发、大数据、鸿蒙、计算机网络、嵌入式物联网、软件测试、数据结构与算法、音视频开发、Flutter、IOS开发、PHP开发、.NET、安卓逆向、云计算