Hystrix 的两种隔离方式

hystrix 隔离模式目前有两种方式：信号量 模式和 线程池 模式。

---

1 为什么进行线程隔离

hystrix的一项核心功能，就是所谓的资源隔离，

资源隔离要解决的最核心的问题，就是将多个依赖服务的调用分别隔离到各自的资源池内。避免对某一个依赖服务的调用，因为依赖服务的接口调用的延迟或者失败，导致服务所有的线程资源全部耗费在这个服务的接口调用上。一旦某个服务的线程资源全部耗尽的话，可能就导致服务就会崩溃，甚至说这种故障会不断蔓延

hystrix，资源隔离提供了两种技术：

1.线程池 资源隔离
2.信号量 资源隔离 (Semaphore)

---

2 线程池与信号量的对比

	是否有线程切换	是否支持异步	是否支持超时	是否支持熔断	是否支持限流	开销大小
线程池	是	是	是	是	是	大
信号量	否	否	否	是	是	小

请求线程和调用provider线程是同一条线程，信号量并不支持超时，当被调服务发生问题时，有少部分用户会长时间无法得到响应。

请求线程和调用provider线程不是同一条线程，线程池模式无法传递Header，我估计是由于线程切换，参数传递过程中被去掉了。

---

3 线程池与信号量隔离技术，分别适用于什么场景

线程池：适合绝大多数的场景。特别是 对其他服务的网络请求与调用存在 timeout 问题时。

如果当前请求的服务，需要耗时很长才能完成服务的响应，为了防止超时，可以使用的线程池杜绝服务因为超时出现问题。

信号量：适合与对内部的一些比较复杂的业务逻辑的访问，而不是对外部依赖的访问。

像这种访问系统内部的代码，其实不涉及网络请求，那么只要做信号量的普通限流就可以了，因为不需要去捕获 timeout 类似的问题，程序在做 “算法+数据结构” 等操作时如果效率不是太高，并发量突然太高，因为比较微耗时，导致很多线程卡在这里的话，不太好，所以进行一个基本的资源隔离和访问，避免内部复杂的低效率的代码，导致大量的线程被hang住。