注：发现一篇好文章忍不住分享一下 PS：感觉写的格式有点乱，整理了一下，并加上了一些自己的看法

原文： https://blog.csdn.net/kang123488/article/details/79512226

一、生产环境线程池的配置的问题
生产环境里面，一个是线程池的大小怎么设置，timeout时长如果设置不合理的话，会出现很多问题
1.超时时间太短低于服务的平均响应时间，正常的功能都无法执行。
2.超时时间太长，浪费系统资源，影响系统的性能
二、如何才能获取线程池合适的配置
接口访问量的不同也导致了线程池配置的不同
在生产环境中部署一个短路器，一开始需要将一些关键配置设置的大一些，比如Timeout超时时长，线程池大小，或信号量容量（这是Hystrix资源隔离的两种方式：线程池和信号量），然后逐渐优化这些配置，直到在一个生产系统中运作良好
1.一开始先不要设置Timeout超时时长，默认就是1000ms，也就是1s
2.一开始也不要设置线程池大小，默认就是10
3.直接部署Hystrix到生产环境，如果运行的很良好，那么就让它这样运行好了
4.让Hystrix应用，24小时运行在生产环境中
5.依赖标准的监控和报警机制来捕获到系统的异常运行情况
6.在24小时之后，看一下调用延迟的占比，以及流量，来计算出让短路器生效的最小的配置数字
7.直接对Hystrix配置进行热修改，然后继续在Hystrix Dashboard上监控
8.看看修改配置后的系统表现有没有改善

三、配置经验
下面是根据系统表现优化和调整线程池大小，队列大小，信号量容量，以及timeout超时时间的经验：
1.假设对一个依赖服务的高峰调用QPS是每秒30次一开始如果默认的线程池大小是10。
2.我们想的是，理想情况下，每秒的高峰访问次数 * 99%的访问延时 + buffer = 30 * 0.2 + 4 = 10线程，10个线程每秒处理30次访问应该足够了，每个线程处理3次访问
3.此时，我们合理的timeout设置应该为300ms，也就是99.5%的访问延时，计算方法是，因为判断每次访问延时最多在250ms（TP99如果是200ms的话），再加一次重试时间50ms，就是300ms，感觉也应该足够了
4.因为如果timeout设置的太多了，比如400ms，比如如果实际上，在高峰期，还有网络情况较差的时候，可能每次调用要耗费350ms，也就是达到了最长的访问时长
5.那么每个线程处理2个请求，就会执行700ms，然后处理第三个请求的时候，就超过1秒钟了，此时会导致线程池全部被占满，都在处理请求。这个时候下一秒的30个请求再进来了，那么就会导致线程池已满，拒绝请求的情况，就会调用fallback降级机制
6.因此对于短路器来说，timeout超时一般应该设置成TP99.5，比如设置成300ms，那么可以确保说，10个线程，每个线程处理3个访问，每个访问最多就允许执行300ms，过时就timeout了。这样才能保证说每个线程都在1s内执行完，才不会导致线程池被占满，然后后续的请求过来大量的reject
7.对于线程池大小来说，一般应该控制在10个左右，20个以内，最少5个，不要太多，也不要太少。大家可能会想，每秒的高峰访问次数是30次，如果是300次，甚至是3000次，30000次呢？？？30000 * 0.2 = 6000 + buffer = 6100，一个服务器内一个线程池给6000个线程把。如果你一个依赖服务占据的线程数量太多的话，会导致其他的依赖服务对应的线程池里没有资源可以用了
6000 / 20 = 300台虚拟机也是ok的
虚拟机，4个cpu core，4G内存，虚拟机，300台
物理机，十几个cpu core，几十个G的内存，5~8个虚拟机，300个虚拟机 = 50台物理机

你要真的说是，你的公司服务的用户量，或者数据量，或者请求量，真要是到了每秒几万的QPS，3万QPS，60 * 3 = 180万访问量，1800，1亿8千，1亿，10个小时，10亿的访问量
app，系统几十台服务器去支撑，我觉得很正常QPS每秒在几千都算多的了

PS：Hystrix资源隔离线程池有一个配置，A、B线程池都有有20个线程，但某一时刻A线程池访问较多，B线程池20个线程并未全部使用，可以配置让A借用B线程池的线程

线程池 资源 优化 演进 在 生产环境 中 部署一个短路器，一开始需要将一些关键 配置 设置的大一些，比如 timeout 超时 时长 ， 线程池 大小 ，或信号量容量，然后逐渐 优化 这些 配置 ，直到在一个 生产 系统 中 运作良好。 （1）一开始先不要设置 timeout 超时 时长 ，默认就是1000ms，也就是1s （2）一开始也... （1）一开始先不要设置 timeout 超时 时长 ，默认就是1000ms，也就是1s （2）一开始也不要设置 线程池 大小 ，默认就是10 （3）直接部署 hystrix 到 生产环境 ，如果运行的很良好，那么就让它这样运行好了 （4）让 hystrix 应用，24小时运行在 生产环境 中 （5）依赖标准的监控和报警机制来捕获到系统的异常运行情况 （6）在24小时之后，看一下调用延迟的占比，以及流量，来计算出让... 当通过 hystrix .threadpool.default.coreSize设置核心线程数量时 创建 线程池 时核心线程数和最大线程数都使用的它 当执行feign逻辑时 会判断当前线程数是否小于最大线程数 所以每次都会新建一个线程来执行网络请求 当请求执行完毕以后由于当前线程数不大于核心线程数(永远满足不了)所以... 在分布式系统 中 ，每个服务都可能会调用很多其他服务，被调用的那些服务就是依赖服务，有 的时候某些依赖服务出现故障也是很正常的。 Hystrix 可以让我们在分布式系统 中 对服务间的调用进行控制，加入一些调用延迟或者依赖故障的容错机制。 Hystrix 通过将依赖服务进行 资源 隔离 ，进而阻止某个依赖服务出现故障时在整个系统所有的依赖服务调用 中 进行蔓延；同时 Hystrix 还提供故障时的 fallback 降级机制。 总而言之， Hystrix 通过这些方法帮助我们提升分布式系统的可用性和稳定性。 Hystrix 的设 源码如下，看完包会 protected static Hystrix CommandProperties.Setter createSetter(IClientConfig config, String commandKey, ZuulProperties zuulProperties) { //获取 Hystrix Timeout ，设置 Hystrix Command的Setter int hystrix Timeout = get Hystrix Timeout (config, commandKey); 一般来说，在调用依赖服务的接口的时候，比较常见的一个问题就是 超时 。 超时 是在一个复杂的分布式系统 中 ，导致系统不稳定，或者系统抖动。出现大量 超时 ，线程 资源 会被 hang 死，从而导致吞吐量大幅度下降，甚至服务崩溃。 你去调用各种各样的依赖服务，特别是在大公司，你甚至都不认识开发一个服务的人，你都不知道那个人的技术水平怎么样，对那个人根本不了解。 Peter Steiner 说过，“On the Int... 生产环境 里面，一个是 线程池 的 大小 怎么设置， timeout 时长 怎么不合理的话，问题还是很大的在 生产环境 中 部署一个短路器，一开始需要将一些关键 配置 设置的大一些，比如 timeout 超时 时长 ， 线程池 大小 ，或信号量容量然后逐渐 优化 这些 配置 ，直到在一个 生产 系统 中 运作良好（1）一开始先不要设置 timeout 超时 时长 ，默认就是1000ms，也就是1s（2）一开始也不要设置 线程池 大小 ，默认就是10（3）直接部署hy... 上一篇文章讲了一个朋友公司使用Spring Cloud架构遇到问题的一个真实案例，虽然不是什么大的技术问题，但如果对一些东西理解的不深刻，还真会犯一些错误。 如果没看过上一篇文章的朋友，建议先看看：【双11狂欢的背后】微服务注册 中 心如何承载大型系统的千万级访问？ 因为本文的案例背景会基于上一篇文章。 这篇文章我们来聊聊在微服务架构 中 ，到底如何保证整套系统的 高可用 ？ 排除掉一些基础设施的故障，比如说Redis集群挂了，Elasticsearch集群故障了，MySQL宕机。 微服务架构本身最最核心的保