hystrix线程池隔离的原理与验证
hystrix隔离原理
hystrix可以完成隔离、限流、熔断、降级这些常用保护功能。这四个功能可以这么来理解：
hystrix的隔离分为线程池隔离和信号量隔离。
信号量隔离原理
信号量隔离就是hystrix的限流功能。虽然名字叫隔离，实际上它是通过信号量来实现的。而信号量说白了就是个计数器。计数器计算达到设定的阈值，直接就做异常处理。
ratelimiter的令牌桶算法和漏桶算法，都是直接对请求量来计数。只是令牌桶算法可以将前面一段时间没有用掉的请求量允许余额拿过继续用。而漏桶算法一段时间就允许这么多，前面没用掉的也不能用了。
而hystrix信号量隔离限制的是tomcat等Web容器线程数，一段时间仅仅能支持这么多。多余的请求再来请求线程资源，就被拒绝了。所以是一种“曲径通幽”的限流方式。因为实际是通过隔离了部分容器线程资源，也算是一种隔离方式。
线程池隔离原理
信号量隔离只是起了个限制作用，它的保护能力有限：如果下游服务有问题，长时间不返回结果。本身信号量隔离对这个单个请求是起不到任何作用的。它只能限制这样的请求太多了就拒绝，不让整个服务挂。
为了解决这个问题，hystrix又产生了线程池隔离。这种隔离方式是通过引入额外线程的方式。对原来的web容器线程做管理控制：如果一个线程超时未返回，则熔断。既然引入额外的线程就涉及线程池管理、线程的上下文切换这些额外的开销。所以相比信号量隔离，线程池隔离成本更高。
熔断原理
隔离不但可以做保护，还可以做统计：成功了多少失败了多少。既然有统计数据了，它就可以进一步处理：失败太多了，说明现在有问题，执行完了再发现失败太浪费资源，干脆就先不让worker线程执行了。过段时间再试试。这就是断路器模式，也就是熔断的原理。
降级原理
任何异常需要熔断的场景，为的都是反正都是错，干脆把这资源省了。直接返回一个预定的错误。这个熔断后返回设定错误的过程就是降级。
资源保护的流程
从上面来看所谓的hystrix的四大功能：限流、隔离、熔断和降级。只是完成了一整个对资源保护的生命周期。来看看对应的BPMN流程图：
信号量隔离的流程
线程池隔离的流程
现在大家请回答我一个问题：我上面说的是对的吗？
hystrix隔离验证
采用淘金式的思维，不要别人说什么都信。网上很多技术博客里说的都是错的。我的文章也有可能是错的，事实上我说的很多东西都带有自己脑补的成分。
既然不确定是否是对的，就要去验证。先验证
1>hystrix隔离确实能限制资源
2>信号量隔离采用的Web容器的线程池，而线程池隔离采用的是自己独立的线程池。
本次验证，Web容器使用的是spring boot内嵌的jetty。代码已经上传github:
https://github.com/xiexiaojing/yuna
信号量隔离验证
隔离hystrix配置
import com.netflix.hystrix.*;import org.slf4j.Logger;import org.slf4j.LoggerFactory;import org.springframework.beans.factory.config.ConfigurableBeanFactory;import org.springframework.context.annotation.Scope;import org.springframework.stereotype.Component;
import java.util.concurrent.TimeUnit;
@Component@Scope(ConfigurableBeanFactory.SCOPE_PROTOTYPE)public class DemoHystrixCommand extends HystrixCommand<String> { private static final Logger logger = LoggerFactory.getLogger(DemoHystrixCommand.class); private String poolName;
public DemoHystrixCommand() { super(Setter.withGroupKey( //服务分组 HystrixCommandGroupKey.Factory.asKey("DemoGroup")) //线程分组 .andThreadPoolKey(HystrixThreadPoolKey.Factory.asKey("DemoPool")) //线程池配置 .andThreadPoolPropertiesDefaults( HystrixThreadPoolProperties.Setter() .withCoreSize(2) .withKeepAliveTimeMinutes(5) .withMaxQueueSize(2) .withQueueSizeRejectionThreshold(10)) //线程池隔离 .andCommandPropertiesDefaults( HystrixCommandProperties.Setter() .withExecutionIsolationStrategy(HystrixCommandProperties.ExecutionIsolationStrategy.SEMAPHORE) ) ); }
@Override protected String run() throws Exception { logger.info(poolName + ":我伤心我无奈,可是我默默等待"); TimeUnit.MILLISECONDS.sleep(100); return poolName + "-run:缘分就是一生的等待"; }
public void setPoolName(String poolName) { this.poolName = poolName; }}调用方
import com.brmayi.yuna.util.DemoHystrixCommand;import org.springframework.beans.factory.annotation.Autowired;import org.springframework.context.ApplicationContext;import org.springframework.web.bind.annotation.GetMapping;import org.springframework.web.bind.annotation.RestController;
import javax.annotation.Resource;
@RestControllerpublic class HystrixController { @Autowired private ApplicationContext applicationContext;
@GetMapping("/hystrix") public String hystrix(String poolName) throws Exception { DemoHystrixCommand demoHystrixCommand = applicationContext.getBean(DemoHystrixCommand.class); demoHystrixCommand.setPoolName(poolName); return demoHystrixCommand.execute(); }}验证
多点几次
多点几次
看日志，日志前缀里Web容器的其他日志线程号和请求hystrix的线程号规则一致，可说明是Web容器的线程。
注意看，不管是倩倩还是萍儿，它们的线程数都没有超过最大线程数
线程池隔离验证
只要将隔离hystrix配置的
HystrixCommandProperties.ExecutionIsolationStrategy.SEMAPHORE改成
HystrixCommandProperties.ExecutionIsolationStrategy.THREAD
重启后重复上面验证步骤
看线程池名变成了隔离hystrix配置的线程名规则！并且不管是倩倩还是萍儿，它们的线程数都没有超过最大线程数。
以上实验说明
1>hystrix隔离确实能限制资源
2>信号量隔离采用的Web容器的线程池，而线程池隔离采用的是自己独立的线程池。
成立。
其他部分限于篇幅，我就不验证了。这里用到了打日志的方法验证线程池情况。如果在生产环境，实际上我们是需要对线程池情况做监控的。可以使用java.lang.management包里的工具注册监控。我们平时使用falcon这样的工具来查看，原理也是先通过java.lang.management包里的工具注册上报信息到服务端采集的。如果自己想查看监控结果，可以用jdk自带的jvisualvm安装一个com-sun-tools-visualvm-modules-mbeans.nbm插件来看。
总结
本篇文章的验证部分很粗糙，限于篇幅，没有把所有需要验证的点覆盖全。想验证我花的hystrix资源保护生命周期的图，至少要结合源码和验证两方面。先当留作业了，有时间我把详细过程补上。
腾讯云开发者
