注：发现一篇好文章忍不住分享一下 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线程池的线程