Hystirx限流：信号量隔离和线程池隔离

背景：
最近工作中要处理服务高并发的问题，大流量场景下限流熔断降级可以说是必不可少的，打算对限流做一次改造，所以要先了解一下hytrix相关内容，比如了解一下线程池隔离和信号量隔离的区别。

**信号量：**信号量Semaphore是一个并发工具类，用来控制可同时并发的线程数，其内部维护了一组虚拟许可，通过构造器指定许可的数量，每次线程执行操作时先通过acquire方法获得许可，执行完毕再通过release方法释放许可。如果无可用许可，那么acquire方法将一直阻塞，直到其它线程释放许可。
区别（HystirxCommand层面）：
semaphore信号量隔离：hystirxCommand将会在调用线程上执行，开销相对较小，但是并发请求受信号量个数限制
thread线程池隔离：使用该方式，HystrixCommand将会在单独的线程上执行，并发请求受线程池中线程数量的限制

线程池隔离的优点：
1.隔离服务的依赖，请求线程可以快速放回
2.当其他线程池出现问题时候，线程池是独立的，不会影响其他服务和接口
3.当服务从不可用状态变为可用状态时，线程池将清理并立即恢复，而不需要一个长时间的恢复
4.独立的线程池提高了线程的并发性

线程池隔离的缺点：
增加了cpu的计算开销，每个命令涉及到的排队，调度，上下文切换都是在一个单独的线程上运行的

信号量隔离：请求线程和调用provider的线程是同一个线程，没有线程切换开销很低，不支持异步，不支持超时
线程池隔离：请求线程和调用provider线程不是同一条线程，因此线程的排队，调度，上下文切换都有开销，支持异步以及超时

---

使用场景：

---

线程池隔离：高并发场景并且耗时较长的情况下，这种情况一般是读数据库或者进行长时间的计算，这样的话可以保证大量的容器线程可用，不会因为服务原因，一直处于阻塞或等待状态，快速失败返回

接收请求和执行下游依赖在同一个线程内完成，不存在线程上下文切换所带来的性能开销，所以大部分场景应该选择信号量模式，但是在下面这种情况下，信号量模式并非是一个好的选择。

比如一个接口中依赖了3个下游：serviceA、serviceB、serviceC，且这3个服务返回的数据互相不依赖，这种情况下如果针对A、B、C的熔断降级使用信号量模式，那么接口耗时就等于请求A、B、C服务耗时的总和，无疑这不是好的方案。

信号量隔离：高并发场景下，耗时较短的情况下，这种情况一般是读缓存，因为这类请求非常快，不太会占用容器线程太长时间，减少了线程切换的开销，提高了缓存服务的效率。

Q&A：
1、实际工作的线程是谁创建的？

使用线程池，实际工作线程由线程池创建；使用Seamphore，实际工作的线程由你自己创建。

2、限流是否自动实现？

线程池自动，Seamphore手动。