说明 ：
1、Hystrix通过舱壁模式来隔离限制依赖的并发量和阻塞扩散
2、 Hystrix提供了两种隔离策略：线程池(THREAD)和信号量隔离SEMAPHORE)。
1. 线程池隔离（默认策略模式）
线程池隔离把执行依赖代码的线程与请求线程（如tomcat线程）分离，请求线程可以*控制离开时间。
通过线程池大小可以控制并发量，当线程池饱和时可以提前拒绝服务，防止依赖问题扩散。
生产环境建议线程池（默认是10个线程）不要设置过大，否则大量堵塞线程可能会拖慢服务器。
优点：
1. 使用线程池隔离可以完全隔离第三方运用，请求线程可以快速放回。
2. 请求线程可以继续接受新的请求，如果出现问题线程池隔离是独立的不会影响其他应用。
3. 当失败的应用在次变得可用时，线程池将清理并可立即恢复，而不需要一个长时间的恢复。
4. 独立的线程提高了并发性。
注意：尽管线程池隔离是由一个单独的线程提供，客户端代码（异常方法里面的请求）应该也有超时机制，不能让响应的线程无限期等待，应该适时的去中断它，阻止Hystrix线程池的饱和
缺点：
线程池隔离的主要缺点是它们增加计算开销（CPU）。每个命令的执行涉及到排队，调度和上下文切换都是在一个单独的线程上运行的。
Netflix在设计这个系统时认为可以接受此开销的费用换取它提供的好处。Netflix内部API每天10+亿的HystrixCommand依赖请求使用线程隔离，每个应用大约40多个线程池，每个线程池大约5—20个线程（大多数都设置为10）。
2. 信号量隔离
使用一个原子计数器（或信号量）来记录当前多少个线程在运行，当请求进来时先判断计数器的数值，若超过设置的最大线程个数则拒绝该请求，若不超过则同行，这时候计数器+1，请求返回成功后计数器-1.
与线程池隔离最大不同在于执行依赖代码的线程依然是请求线程。
tips：信号量的大小可以动态调整，线程池不可以。
3. 信号量隔离的使用
在@HystrixCommand里面添加commandProperties配置，如下：
@HystrixCommand(fallbackMethod="findByIdFallback",commandProperties={@HystrixProperty(name="execution.isolation.strategy", value="SEMAPHORE")})
4. 应用场景
线程池隔离：
1.第三方应用或者接口
2. 并发量大
信号量隔离
1. 内部应用或者中间件（redis）
2. 并发需求不大