Hystrix 熔断机制原理

相关配置

circuitBreaker.enabled  是否开启熔断
circuitBreaker.requestVolumeThreshold  熔断最低触发请求数阈值
circuitBreaker.sleepWindowInMilliseconds  产生熔断后恢复窗口
circuitBreaker.errorThresholdPercentage  错误率阈值
circuitBreaker.forceOpen  强制打开熔断
circuitBreaker.forceClosed  强制关闭熔断

状态图

执行流程

命令执行前调用circuitBreaker.attemptExecution(),正常情况下会执行返回true,但是如果发生熔断,则需要通过sleepWindows来进行恢复

public boolean attemptExecution() {
    if (properties.circuitBreakerForceOpen().get()) {
        return false;
    }
    if (properties.circuitBreakerForceClosed().get()) {
        return true;
    }
    if (circuitOpened.get() == -1) {
        return true;
    } else {
        if (isAfterSleepWindow()) {
            if (status.compareAndSet(Status.OPEN, Status.HALF_OPEN)) {
                //only the first request after sleep window should execute
                return true;
            } else {
                return false;
            }
        } else {
            return false;
        }
    }
}

发生熔断流程

在新版本1.5.12中,会有一个后台线程订阅metrics流实时计算:

  1. 如果没有达到RequestVolume,则直接返回,不计算是否需要熔断
  2. 如果当前错误率大于设置的阈值,则触发熔断,状态由CLOSED切换到OPEN,并设置当前熔断的时间(用于后续SleepWindows判断使用)
    if (hc.getTotalRequests() < properties.circuitBreakerRequestVolumeThreshold().get()) {
    // we are not past the minimum volume threshold for the stat window,
    // so no change to circuit status.
    // if it was CLOSED, it stays CLOSED
    // if it was half-open, we need to wait for a successful command execution
    // if it was open, we need to wait for sleep window to elapse
    } else {
    if (hc.getErrorPercentage() < properties.circuitBreakerErrorThresholdPercentage().get()) {
        //we are not past the minimum error threshold for the stat window,
        // so no change to circuit status.
        // if it was CLOSED, it stays CLOSED
        // if it was half-open, we need to wait for a successful command execution
        // if it was open, we need to wait for sleep window to elapse
    } else {
        // our failure rate is too high, we need to set the state to OPEN
        if (status.compareAndSet(Status.CLOSED, Status.OPEN)) {
            circuitOpened.set(System.currentTimeMillis());
        }
    }
    }

熔断恢复流程

当发生熔断,达到SleepWindows指定时间后,则状态会由OPEN转换为HALF_OPEN,此时只会让一个请求通过,如果该请求执行成功,状态则会转换为CLOSED,否则会回到OPEN状态,并且熔断时间设置为当前时间,重新等待SleepWindows的时间

// 执行成功后调用
public void markSuccess() {
    if (status.compareAndSet(Status.HALF_OPEN, Status.CLOSED)) {
        //This thread wins the race to close the circuit - it resets the stream to start it over from 0
        metrics.resetStream();
        Subscription previousSubscription = activeSubscription.get();
        if (previousSubscription != null) {
            previousSubscription.unsubscribe();
        }
        Subscription newSubscription = subscribeToStream();
        activeSubscription.set(newSubscription);
        circuitOpened.set(-1L);
    }
}
// 执行失败后调用
public void markNonSuccess() {
    if (status.compareAndSet(Status.HALF_OPEN, Status.OPEN)) {
        //This thread wins the race to re-open the circuit - it resets the start time for the sleep window
        circuitOpened.set(System.currentTimeMillis());
    }
}

参考

  1. https://github.com/Netflix/Hystrix/wiki/Configuration
  2. https://github.com/Netflix/Hystrix/wiki/How-it-Works#CircuitBreaker
  3. HystrixCircuitBreaker源码

原文地址:https://www.cnblogs.com/jabnih/p/9013197.html

时间: 2024-07-29 14:29:38

Hystrix 熔断机制原理的相关文章

SpringCloud系列七:Hystrix 熔断机制(Hystrix基本配置、服务降级、HystrixDashboard服务监控、Turbine聚合监控)

1.概念:Hystrix 熔断机制 2.具体内容 所谓的熔断机制和日常生活中见到电路保险丝是非常相似的,当出现了问题之后,保险丝会自动烧断,以保护我们的电器, 那么如果换到了程序之中呢? 当现在服务的提供方出现了问题之后整个的程序将出现错误的信息显示,而这个时候如果不想出现这样的错误信息,而希望替换为一个错误时的内容. 一个服务挂了后续的服务跟着不能用了,这就是雪崩效应 对于熔断技术的实现需要考虑以下几种情况: · 出现错误之后可以 fallback 错误的处理信息: · 如果要结合 Feign

spring cloud 2.x版本 Ribbon服务发现教程(内含集成Hystrix熔断机制)

本文采用Spring cloud本文为2.1.8RELEASE,version=Greenwich.SR3 前言 本文基于前两篇文章eureka-server和eureka-client的实现. 参考 eureka-server eureka-client 1 Ribbon工程搭建 1.1 创建spring boot工程:eureka-ribbon 1.2 pom.xml所需要依赖的jar包 <dependency> <groupId>org.springframework.clo

hystrix熔断机制修改配置

一.修改参数 设置参数有3个地方:通过日志 2018-02-12 18:07:36.876 DEBUG HystrixPropertiesChainedProperty:93 - Flipping property: hystrix.command.HttpPostCommand.execution.isolation.thread.timeoutInMilliseconds to use NEXT property: hystrix.command.default.execution.isol

Hystrix熔断机制导致误报请求超时错误

问题的过程如下: (1)前端向服务端请求往HBase插入1000条数据: (2)请求经路由网关Zuul传递给HBaseService,HBaseService执行插入操作: (3)插入操作需要的时间超过Zuul设定的阈值,Zuul判定HBaseService服务下线,报错并向前端返回请求超时信息: (4)插入操作正确执行: 原文地址:https://www.cnblogs.com/ratels/p/11106443.html

SpringCloud 基础教程(五) 服务熔断机制(Eureka + Ribbon + Hystrix)

1.启动[服务中心]集群,即 Eureka Server 参考 SpringCloud 基础教程(一) 服务中心及集群(Eureka Server) 2.启动[服务提供者]集群,即 Eureka Client 参考 SpringCloud 基础教程(二) 服务注册及集群(Eureka Client) 3.启动[服务消费者],即 Eureka Discovery Client 参考 SpringCloud 基础教程(三) 服务发现及负载均衡(Eureka Discovery Client + Ri

熔断机制hystrix

一.问题产生 雪崩效应:是一种因服务提供者的不可用导致服务调用者的不可用,并将不可用逐渐放大的过程 正常情况下的服务: 某一服务出现异常,拖垮整个服务链路,消耗整个线程队列,造成服务不可用,资源耗尽: 形成过程: 1)服务提供者不可用 a)硬件故障:硬件损坏造成的服务器主机宕机, 网络硬件故障造成的服务提供者的不可访问 b)程序Bug: c)   缓存击穿:缓存击穿一般发生在缓存应用重启, 所有缓存被清空时,以及短时间内大量缓存失效时. 大量的缓存不命中, 使请求直击后端,造成服务提供者超负荷运

网关中加入熔断机制(Hystrix)

网关中加入熔断机制 在网关中加入熔断机制 添加依赖项 spring-cloud-gateway项目POM文件加入spring-cloud-starter-netflix-hystrix <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-hystrix</artifactId> </depende

利用Spring Cloud实现微服务- 熔断机制

1. 熔断机制介绍 在介绍熔断机制之前,我们需要了解微服务的雪崩效应.在微服务架构中,微服务是完成一个单一的业务功能,这样做的好处是可以做到解耦,每个微服务可以独立演进.但是,一个应用可能会有多个微服务组成,微服务之间的数据交互通过远程过程调用完成.这就带来一个问题,假设微服务A调用微服务B和微服务C,微服务B和微服务C又调用其它的微服务,这就是所谓的"扇出".如果扇出的链路上某个微服务的调用响应时间过长或者不可用,对微服务A的调用就会占用越来越多的系统资源,进而引起系统崩溃,所谓的&

springcloud熔断机制

最近项目用到springcloud,研究了下springcloud的熔断机制Hystrix. 熔断机制,就是下游服务出现问题后,为保证整个系统正常运行下去,而提供一种降级服务的机制,通过返回缓存数据或者既定数据,避免出现系统整体雪崩效应.在springcloud中,该功能可通过配置的方式加入到项目中. 理论上需要进行分布式调用的服务都应该加上,在项目中,可根据实际项目需要进行添加. Maven项目中提供远程调用Feign中已经依赖了Hystrix,所以在项目的pom配置上不用做任何改动. 实现步