# hytrixZZ

**Repository Path**: interview_44/hytrix-zz

## Basic Information

- **Project Name**: hytrixZZ
- **Description**: hytrix学习
- **Primary Language**: Java
- **License**: Not specified
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 0
- **Created**: 2021-04-25
- **Last Updated**: 2023-02-25

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

# hytrixZZ

#### 介绍
hytrix学习

-[1、高qps场景&hystrix](#1高qps场景hystrix)

-[2、系统故障蔓延](#2系统故障蔓延)

-[3、hystrix内部分析](#3hystrix内部分析)

-[4、hystrix执行时的8大流程步骤](#4hystrix执行时的8大流程步骤)

### 1、高qps场景&hystrix

![](./picture/1、高qps场景.png)

当有亿级用户同事访问的时候，需要大量使用缓存保护数据库被高并发挤死，分布式集群模式部署服务器。

timeOut超时：是在复杂的分布式系统中，导致系统不稳定，线程hand死，吞吐量大幅度下降，服务崩溃。

利用mq削峰，大量的访问请求都堆积在mq上，等mq慢慢消化。

如果服务器挂了，影响非常大的业务量，损失十分严重。

so，需要一个技术，保护服务器，不让服务器因为高并发而挂掉。

spring cloud就是基于hystrix做微服务架构


hystrix：
1、失败和容错保护。
2、阻止故障蔓延，A->B->C。
3、快速失败快速恢复。
4、forback降级，服务优雅降级。
5、监控、报警、运维。


hystrix工作原理:
1、资源隔离。
2、请求缓存。
3、熔断。
4、限流。
5、降级。
6、请求超时。

资源隔离：一块代码，最多10个线程，无节制的申请资源系统就挂了，所以要限定好资源。

限流：每秒100万qps,10万进入系统，90万qps被拒。

熔断：后端服务出现故障，例如mysql挂了，每次请求失败，后续的请求就不接受了，拒绝访问，10分钟后再去尝试看看mysql是否恢复。

降级：mysql挂了，系统发现后自动降级，从内存中的数据中，取一些数据。

hystrix  限流机制  -   仓壁隔离：

判断线程池或者信号量是否已满，已满->reject，限流。

线程池做到了资源隔离，任何一个服务，不会被单个接口拖垮。

线程池给性能上带来了一些开销，访问慢几毫秒，保证了服务的可用性。

coreSize：线程池大小。
MaxqueueSize：等待队列大小。
timeout：设置超时时间。
fallback：进入限流请求个数。

### 2、系统故障蔓延

![](./picture/2、依赖服务导致故障蔓延.png)

首先C服务器宕机了。先服务器先有10个请求进入，等待回应，阻塞，再来10个，再来10个。。。。。

任何系统运行，都有一个总线程资源，同时刻支持最大并发数。上图服务B，100个线程调用服务C，100个线程资源都卡在服务B，资源耗尽。无法处理请求，宕机。

C宕机导致B宕机，导致A宕机，一路蔓延，整条链路。

so：
资源隔离

如何保护服务依赖，把服务B的线程资源按照一定比率分配。

![](./picture/3、资源隔离.png)

如果我们设置掉C的最大线程只有40个，那么最多也就是40个线程阻塞，整个服务器都是可用的，故障得到控制，没有被蔓延。

### 3、hystrix内部分析

hystrix提供资源隔离，提供了抽象command。

如果要对某一个依赖服务隔离在一个线程池内，所有请求走这个资源池。就是hystrix的最基本隔离技术，线程池隔离技术。

该服务的每次请求都封装在一个command里面，每次command都会使用线程池一个线程，如果10万个请求但是线程池只有10个线程，只会执行10个请求。

Command支持同步跟异步调用,异步对象会调用queue，立即返回further，随后用further.get（）拿到后续的结果。

command：有2个使用方法。

a、HystrixCommand  用在依赖服务返回单个操作结果的时候，99.99%的情况下我们使用的是它。

b、HystrixObservableCommand 用在依赖服务返回多个操作结果的时候，其实可以认为返回的是个事件发射器，可以持续发射数据。

hystrix提供2种资源隔离技术：

a、线程池资源隔离：适合99%的场景，对服务网络请求，出现timeout这种。线程池隔离技术，并不是说，去控制类似tomcat这种web容器的线程。更加严格意义上说来，hytrix的线程池隔离技术，控制的是tomcat线程的执行。确保的是tomcate线程不会因为依赖服务接口调用延迟或者故障，被hang
住，执行fallback，执行fallback后立即返回，tomcat线程就得到返回，不会把资源撑爆。

b、信号量资源隔离：适合访问不对外的请求，对内部复杂业务逻辑调用，不会出现网络超时，那么只用信号量这种普通限流就可以了，不需要使用timeout，因为复杂的代码会使线程卡在这里，所以使用一个基本的资源隔离和访问避免低消代码。信号量资源隔离，只是一道官咖，tomcat线程来了10个，那么第11个就直接fallback立即返回。有点，不用自己管理线程池，性能高一些。

![](./picture/4、线程池与信号量的区别.png)

资源隔离：隔离策略细粒度控制：
每个command都设置自己的名称与组，默认情况下一个组是一个线程池

command   threadpool -> command group -> command key

command key：对应一个接口。

command group：对应一个底层的依赖服务，一个服务有多个接口，每个接口解释key，在逻辑上组织起一堆command key  统计信息，成功次数，失败次数，timeoit时间，看到某一个服务的运行情况。

threadpool：可以对应group（一般用法），也可以对应每一个key（接口单独设置线程池）。

### 4、hystrix执行时的8大流程步骤

![](./picture/5、八大流程步骤.png)


1、创建command，执行。查看requestCacher是否有缓存，有则直接返回缓存数据即可。

2、没有缓存，进入断路器circuit breaker。断路器打开，直接返回，断路器没打开，往下走。

3、获取线程池/信号量资源，是否已满，满了，就返回吧，打开断路器。

4、还有线程资源，执行command的方法，执行情况是否timeout。出现请求超时，则执行降级fallback，command的fallback提供降级服务。不实现该服务，降级时会报错，无降级服务。每有降级的反馈都会发给断路器，异常到达一定比例就会自动短路。

5、执行command的结果是否正常，异常也会返回给断路器circuit breaker。

a、hystrix的requestCacher，新建一个fither，配置启动使用，重写方法，把查询结果存入缓存里面，只有相同的查询参数，就会获取到缓存的数据，亦可以自定义清楚缓存，把key对应的缓存数据删除掉。

b、hystrix的fallback降级机制：调用接口，访问依赖，如果出现任何异常情况；对外部资源，只能用一定量的资源访问；访问时间过长。以上3种事件会发到断路器，进行服务降级fallback，fallback
也是有最大请求数量的，防止高并发打死程序。

c：hystrix：10秒内经过断路器的请求超过限定条件默认10，请求返回异常的比例达到一定数量默认50%，就会开启断路器。close->open，断路器会自动恢复（默认5000ms）  ->  半开状态,尝试让请求执行，执行成功 open->close。

### 5、histrix核心要点

1、资源隔离：多个服务，可以做资源隔离，防止故障蔓延。

2、请求缓存：同样的请求，直接在缓存中获取，无序在调用网络资源。

3、熔断：基于断路器，采集异常、报错、超时、reject、短路、熔断，一定时间内不允许访问，直接降级，自动恢复。

4、降级：提供降级服务，直接返回友情提示，不在消耗资源。

5、限流：资源池用完了资源就排队，队列满了就直接降级，防止资源滥用。

6、超时：设定接口超时时间，防止服务器资源长期占用，宕机。