Hystrix面试要点总结

使用场景

一般是微服务或者涉及到调用外部系统的场景（有I/O操作）。

解决了什么问题

简单来说，就是阻止某一个依赖服务的故障在整个系统中蔓延。具体有如下措施：

资源隔离

线程池隔离

可以为每个服务分配一个线程池，我们的代码是交给hystrix创建的线程执行的，而不是调用线程（比如tomcat的工作线程）。好处是当一个服务出现故障无法正常响应请求，导致线程池的线程耗尽，也不会影响当前服务对其他服务的调用。

信号量隔离

为每个服务分配一个Semaphore，这种用法感觉更像是限流，我们的代码是调用线程执行的，通过Semaphore控制并行调用微服务的线程数。

熔断机制

当所依赖的服务出现故障时，断路器能保护当前服务不会出现资源耗尽的情况，说白了就是防止线程全部阻塞在等待响应上。hystrix对每个请求都会进行记录并统计，当异常比达到50%时就会触发断路器。当断路器为打开状态时，不会去调用外部服务，而是会快速失败并执行fallback（执行降级逻辑）。

fallback

提供fallback优雅降级的支持。就算系统故障了，那也得给客户端（调用方）一个响应吧。这个降级方案中的的数据有两个来源：

• 缓存的数据
• 默认值

总体流程

断路器执行原理

Hystrix 断路器有三种状态，分别是关闭（Closed）、打开（Open）与半开（Half-Open），三种状态转化关系如下：

• Closed： 断路器关闭，调用下游的请求正常通过
• Open：断路器打开，阻断对下游服务的调用，直接走 Fallback 逻辑
• Half-Open：断路器处于半开状态，等待SleepWindowInMilliseconds后，从Open变为Half-Open

如何统计失败率

以滑动窗口为单位来统计失败率，滑动窗口中请求数至少要达到20个才会统计，为什么？因为只有样本数量达到一定规模时统计才有参考价值。试想一下，总共就两个请求，失败一个，失败率就达到50%了，此时打开断路器显然不合适。