这是我参与更文挑战的第2天，活动详情查看： 更文挑战

上一篇文章-Hystrix原理及设计原则
提到分布式系统存在服务雪崩效应，应使用Hystrix断路器实现资源隔离避免服务雪崩效应

Hystrix隔离策略选择

Hystrix实现资源隔离

有两种策略分别是

• 线程池隔离
• 信号量隔离

通过execution.isolation.strategy指定HystrixCommand.run()的资源隔离策略:Thread（线程池） 或 semaphore（信号量）

HystrixCommandProperties.Setter().withExecutionisolationStrategy(ExecutionlsolationStrategy.THREAD)
HystrixCommandProperties.Setter().withExecutionisolationStrategy(ExecutionisolationStrategy.SEMAPHORE)
复制代码

线程池机制，每个command运行在同一个线程池中，限流是通过线程池的大小来控制，信号量机制，每个command是运行在调用线程中，通过信号量的容量来进行限流

如何在线程池和信号量做选择？

默认的策略是线程池，线程池最大的好处就是对于网络访问请求，如果有超时的话，可以避免调用线程阻塞住；
而使用信号量的场景，通常是针对超大并发量的场景下，每个服务实际每秒都几百GPS，此时用线程池，则线程一般不会太多，可撑不住高并发，如果要撑住，可能耗费大量的线程资源，那就使用信号量，来进行限流保护，一般用信号量常见于基于纯内存的一些业务逻辑服务，而不涉及到任何网络访问请求。

使用线程池隔离，怎样对依赖服务、依赖服务接口、线程池三者做区分呢？

区分关键在于command key和command group，每一个command,可设置一个自己名称command key,同时可设置一个自己的组command group

command key 代表了一类command，代表了底层的依赖服务的一个接口

command group 代表了某一个底层的依赖服务，一个依赖服务可能会暴露多个接口，每个接口就是一个command key,command group 在逻辑上组织一堆command key的调用、统计信息，比如成功次数、timeout超时次数、失败次数等，可看到某个服务整体的一些访问情况，推荐根据一个服务区划分出一个线程池，command key默认都是属于同一个线程池。