希望长大对我而言，是可以做更多想做的事，而不是被迫做更多不想做的事...... 首页

hystrix基础

丁D
学无止境
2019-08-06 13:37
41897已阅读

hystrix 资源隔离限流

摘要本文将介绍hystrix，并说明如何使用hystrix进行资源隔离，限流。

###hystrix是什么
在分布式系统中，一个系统通常会有多个依赖项目，那么不可避免的是依赖项目可能会失败，如果主项目没有跟依赖项进行隔离，那么就会有越来越多的线程hang住在调用依赖项的地方等待超时，这样会消耗大量的服务器资源，从而导致主项目被依赖项目拖死。

![alt](/upload/微信图片_20190806135002.png
)

###Hystrix设计原则
1. 提供快速失败，降级功能；
2. 资源隔离防止单个依赖项占用所有tomcat资源（线程）
3. Hystrix两种封装，4种调用方式
4. 线程池隔离，和信号量隔离

###资源隔离
使用Hystrix进行资源隔离，Hystrix提供了一种抽象叫做command，就是说，我们将对同一个依赖项目的调用请求，全部隔离到一个资源池内，，对这个服务的调用，全部使用这个资源池里面的线程，这就是资源隔离。

假设线程池里面只有10个线程，即使这个时候请求有1000个，那也只是使用10个线程去请求，其他的会放在等待队列，等待队列满了就直接调用快速失败方法。这样就不会出现由于接口的调用延迟，将tomcat内的线程全部耗尽。

**Hystrix 两种策略，线程池隔离，信号量隔离**
**Hystrix最基本的隔离技术是，线程池隔离（默认），在实际应用中也是90%使用这个。**

指定了HystrixCommand.run()的资源隔离策略，THREAD或者SEMAPHORE，一种是基于线程池，一种是信号量

线程池机制，每个command运行在一个线程中，限流是通过线程池的大小来控制的

信号量机制，command是运行在调用线程中，但是通过信号量的容量来进行限流

线程池其实最大的好处就是对于**网络访问请求**，如果有超时的话，可以避免调用线程阻塞住

而使用信号量的场景，通常是针对超大并发量的场景下，每个服务实例每秒都几百的QPS，那么此时你用线程池的话，线程一般不会太多，可能撑不住那么高的并发，如果要撑住，可能要耗费大量的线程资源，那么就是用信号量，来进行限流保护

一般用信号量常见于那种基于**纯内存的一些业务逻辑服务**，而不涉及到任何网络访问请求

**线程池机制的缺点：**每一个commod都要有一个独立的线程执行，这就涉及要了 线程的排队，调度，上下文切换，这就有性能的损耗，但是对于系统的稳定性，这一点点的性能损耗完全是可以接受的，

```js
// to use thread isolation
HystrixCommandProperties.Setter().withExecutionIsolationStrategy(ExecutionIsolationStrategy.THREAD)
// to use semaphore isolation
HystrixCommandProperties.Setter().withExecutionIsolationStrategy(ExecutionIsolationStrategy.SEMAPHORE)
```

```js
<dependency>
    <groupId>com.netflix.hystrix</groupId>
    <artifactId>hystrix-core</artifactId>
    <version>1.5.12</version>
</dependency>
```

```js
//HystrixCommandGroupKey 一般一个依赖服务使用同一个线程池orderGroup  
public class CommandOrderInfo extends HystrixCommand<OrderInfo> {

private final String orderId;

public CommandHelloWorld(String orderId) {
        super(HystrixCommandGroupKey.Factory.asKey("orderGroup"));
        this.orderId= orderId;
    }

@Override
    protected String run() {
        //发送http请求调用订单系统获取订单，返回json，转成orderInfo对象返回
        //调用省略。。。。  
        return orderInfo
    }
}

//调用  同步
new CommandOrderInfo("MO123456").execute()
//调用  异步(很少用)
new CommandHelloWorld("World").queue()
对command调用queue()，仅仅将command放入线程池的一个等待队列，就立即返回，拿到一个Future对象，后面可以做一些其他的事情，然后过一段时间对future调用get()方法获取数据（先判断是否执行完成）
```

####command名称和command组
```js
每个command都需要一个command key默认是（类名），每个command代表的是一个接口

command可以归属一个command组代表一个服务，，这个服务所有的，这样就可以聚合一些监控和报警信息.
最佳实践就是 一个command组代表一个服务，，这个服务所有的command都设置同一个command组，这就可以统计这个服务的一些监控信息和报警信息。

每个command可以设置一个线程池，也可以多个command共享一个线程池里面的线程。。。
线程池和command组没有关系  但是默认情况下，一个command组就会创建一个线程池，组内所有的command共享这个线程池的线程。

你的每个command，都可以设置一个自己的名称(默认类名)，同时可以设置一个自己的组

private static final Setter cachedSetter =setter.withGroupKey(HystrixCommandGroupKey.Factory.asKey("ExampleGroup")).andCommandKey(HystrixCommandKey.Factory.asKey("HelloWorld"));    
public CommandHelloWorld(String name) {
    super(cachedSetter);
    this.name = name;
}

```  
command group，是一个非常重要的概念，默认情况下，因为就是通过command group来定义一个线程池的，而且还会通过command group来聚合一些监控和报警信息

同一个command group中的请求，都会进入同一个线程池中

####command线程池
threadpool key代表了一个HystrixThreadPool，用来进行统一监控，统计，缓存

**默认的threadpool key就是command group名称
**每个command都会跟它的threadpool key对应的thread pool绑定在一起

如果不想直接用command group，也可以手动设置thread pool name
```js
public CommandHelloWorld(String name) {
    super(Setter.withGroupKey(HystrixCommandGroupKey.Factory.asKey("ExampleGroup"))
            .andCommandKey(HystrixCommandKey.Factory.asKey("HelloWorld"))
            .andThreadPoolKey(HystrixThreadPoolKey.Factory.asKey("HelloWorldPool")));
    this.name = name;
}

```

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

**command group**，代表了某一个底层的**依赖服务**，合理，一个依赖服务可能会暴露出来多个接口，**每个接口就是一个command key**

**command group**，在逻辑上去组织起来一堆command key的调用，统计信息，成功次数，timeout超时次数，失败次数，可以看到某一个服务整体的一些访问情况

**command group，一般来说，推荐是根据一个服务去划分出一个线程池，command key默认都是属于同一个线程池的**

**command group**，对应了一个服务，但是这个服务暴露出来的几个接口，**访问量很不一样**，差异非常之大

你可能就希望在这个服务command group内部，包含的对应多个接口的command key，做一些细粒度的资源隔离，也就是对**同一个服务的不同接口，都使用不同的线程池**

command key -> command group

command key -> 自己的threadpool key

逻辑上来说，多个command key属于一个command group，在做统计的时候，会放在一起统计

每个command key有自己的线程池，每个接口有自己的线程池，去做资源隔离和限流

但是对于thread pool资源隔离来说，可能是希望能够拆分的更加一致一些，比如在一个功能模块内，对不同的请求可以使用不同的thread pool

command group一般来说，可以是对应一个服务，多个command key对应这个服务的多个接口，多个接口的调用共享同一个线程池

如果说你的command key，要用自己的线程池，可以定义自己的threadpool key，就ok了

####coreSize
```js
//设置线程池的大小，默认是10，一般来说，用这个默认的10个线程大小就够了
HystrixThreadPoolProperties.Setter().withCoreSize(int value)
```

5、queueSizeRejectionThreshold

控制queue满后reject的threshold，因为maxQueueSize不允许热修改，因此提供这个参数可以热修改，控制队列的最大大小

HystrixCommand在提交到线程池之前，其实会先进入一个队列中，这个队列满了之后，才会reject
```js
//默认值是5
HystrixThreadPoolProperties.Setter().withQueueSizeRejectionThreshold(int value)
```

####execution.isolation.semaphore.maxConcurrentRequests

设置使用**SEMAPHORE**隔离策略的时候，允许访问的最大并发量，超过这个最大并发量，请求直接被reject

这个并发量的设置，跟线程池大小的设置，应该是类似的，但是基于信号量的话，性能会好很多，而且hystrix框架本身的开销会小很多

默认值是10，设置的小一些，否则因为信号量是基于调用线程去执行command的，而且不能从timeout中抽离，因此一旦设置的太大，而且有延时发生，可能瞬间导致tomcat本身的线程资源本占满
```js

HystrixCommandProperties.Setter().withExecutionIsolationSemaphoreMaxConcurrentRequests(int value)
```

[官网](https://github.com/Netflix/Hystrix/wiki/How-To-Use)

上一篇：redis哨兵

下一篇：hystrix工作原理及高级特性