Sentinel熔断规则原理示例详解分析

目录
  • 概述
  • 熔断(降级)策略
    • 慢调用比例
      • 概念
      • 测试
    • 异常比例
      • 概念
      • 测试
    • 异常数
      • 概念
      • 测试

概述

除了流量控制以外,对调用链路中不稳定的资源进行熔断降级也是保障高可用的重要措施之一。

由于调用关系的复杂性,如果调用链路中的某个资源不稳定,最终会导致请求发生堆积。

Sentinel 熔断降级会在调用链路中某个资源出现不稳定状态时(例如调用超时、异常比例升高、异常数堆积)

对这个资源的调用进行限制,让请求快速失败从而避免影响到其它的资源而导致级联错误。

当资源被降级后,在接下来的降级时间窗口之内会对该资源的调用自动熔断

(默认行为是抛出 DegradeException)。

综上可知:

  • 熔断是用来避免服务架构中的雪崩的发生
  • 当监控到链路中的异常(响应时间超时、异常比例升高、异常数堆积)达到阈值自动触发熔断
  • 在降级时间窗口之内会对该资源的调用自动熔断

熔断(降级)策略

慢调用比例

概念

慢调用比例 (SLOW_REQUEST_RATIO):

选择以慢调用比例作为阈值,需要设置允许的慢调用 RT(即最大的响应时间),

请求的响应时间大于该值则统计为慢调用。

当单位统计时长(statIntervalMs)内请求数目大于设置的最小请求数目,

并且慢调用的比例大于阈值,则接下来的熔断时长内请求会自动被熔断。

经过熔断时长后熔断器会进入探测恢复状态(HALF-OPEN 状态),

若接下来的一个请求响应时间小于设置的慢调用 RT 则结束熔断,若大于设置的慢调用 RT 则会再次被熔断。

注意Sentinel默认统计的RT上限是4900ms,超出此阈值的都会算作4900ms,

若需要变更此上限可以通过启动配置项-Dcsp.sentinel.statistic.max.rt=xxx来配置

测试

我们在Sentinel DashBoard界面点击熔断规则,然后按照下图配置新增慢调用比例的熔断规则。

如下所示

然后我们在浏览器访问http://localhost:8990/test/hello,连续快速刷新该请求,可以看到服务被熔断。30s后自动恢复

我们本次使用的Sentinel版本是1.8.2,在1.8之前的版本慢调用比例就是RT,

慢调用相较于之前的RT加入了比例阈值,相当于多加了一个条件。

慢调用比例的熔断时机:在统计时长内,请求数大于5个,如若大于指定比例阈值的请求数的响应时间都大于最大RT,

那么会熔断该服务,熔断时间为设置的熔断时长

异常比例

概念

异常比例 (DEGRADE_GRADE_EXCEPTION_RATIO):当资源的每秒请求量 >= N(可配置),

并且每秒异常总数占通过量的比值超过阈值(DegradeRule 中的 count)之后,

资源进入降级状态,即在接下的时间窗口(DegradeRule 中的 timeWindow,以 s 为单位)之内,

对这个方法的调用都会自动地返回。

异常比率的阈值范围是 [0.0, 1.0],代表 0% - 100%。

测试

相较于慢调用比例,异常比例就简单了,通过修改或者新增熔断规则我们可以发现当我们选择异常比例时,

只是比慢调用比例少了一个RT。

我们按照下图所示配置异常比例的熔断规则,如下所示:

为了演示异常我们修改下TestController.java中的/test/hello方法。

如下所示:

@RequestMapping("/hello")
public String sayHello(Integer id){
  log.info("Hello, Sentinel!");
  if(id < 0){
    throw new RuntimeException();
  }
  return "Hello, Sentinel!";
}

然后我们在浏览器访问http://localhost:8990/test/hello?id=-1,连续快速刷新该请求,

当请求数大于5个且异常比例阈值大于0.1时就会自动熔断

这是一个拼手速的实验,点击速度慢的小伙伴可以把统计时长调长一些(默认最大为4900ms)

异常数

概念

异常数 (DEGRADE_GRADE_EXCEPTION_COUNT):当资源近 1 分钟的异常数目超过阈值之后会进行熔断。

注意由于统计时间窗口是分钟级别的,若 timeWindow 小于 60s,

则结束熔断状态后仍可能再进入熔断状态。

测试

相比于前面两个异常数就更简单了,我们按下图所示修改熔断规则。

如图所示:

还是使用测试异常比例的demo进行演示这个效果,我们在浏览器狂刷请求http://localhost:8990/test/hello?id=-1,

放异常数达到5个后就会自动熔断该服务了。

如下图所示:

以上就是Sentinel熔断规则原理示例详解分析的详细内容,更多关于Sentinel熔断规则的资料请关注我们其它相关文章!

(0)

相关推荐

  • Java RPC框架熔断降级机制原理解析

    熔断与降级 为什么在RPC环节中有熔断以及降级的需求,详细的原因这里不多解释,从网上搜索一张图做示意. 熔断 我理解熔段主要解决如下几个问题: 当所依赖的对象不稳定时,能够起到快速失败的目的快速失败后,能够根据一定的算法动态试探所依赖对象是否恢复 比如产品详细页获取产品的好评总数时,由于后端服务异常导致客户端每次都需要等到超时.如果短时间内服务不能恢复,那么这段时间内的所有请求时间都将是最大的超时时间,这类消费时间又得不到正确结果的现象是不能容忍的.所以遇到这类情况,就需要根据一定的算法判定服务

  • Springcloud hystrix服务熔断和dashboard如何实现

    服务在经过一定负荷之后,如果达到一定上限之后会中断进行报错,而服务调用的方法也会报错等等,一旦整体服务停下,别的客户端再来访问就会无法调用.对此需要进行另外一种服务熔断模式. 不同于现实中的熔断保险丝,服务熔断是在系统服务达到一定错误之后,自动熔断降级,采取备用方法,但是在一定时间后客户端再次调用成功后,一定时间内成功率上去,系统的熔断机制会慢慢的关闭,恢复到正常请求的状态. 本篇接上一章直接改动. 1.主启动类加上新的注解. @EnableCircuitBreaker 2.service写入新

  • SpringCloud-Alibaba-Sentinel服务降级,热点限流,服务熔断

    前言: 除了流量控制以外,对调用链路中不稳定的资源进行熔断降级也是保障高可用的重要措施之一.一个服务常常会调用别的模块,可能是另外的一个远程服务.数据库,或者第三方 API 等.例如,支付的时候,可能需要远程调用银联提供的 API:查询某个商品的价格,可能需要进行数据库查询.然而,这个被依赖服务的稳定性是不能保证的.如果依赖的服务出现了不稳定的情况,请求的响应时间变长,那么调用服务的方法的响应时间也会变长,线程会产生堆积,最终可能耗尽业务自身的线程池,服务本身也变得不可用 熔断策略 Sentin

  • Java看完秒懂版熔断和降级的关系

    目录 降级 熔断 什么是服务熔断 熔断和降级的关系 降级方式 1.熔断降级(不可用) 2.超时降级 3.限流降级 完 刚开始我以为熔断和降级是一体的,以为他们必须配合使用: 只不过名字不一样而已,但是当我经过思考过后,发现他们其实不是一个东西; 降级 什么是服务降级呢?降级主要有以下几种情况 超时:当下游的服务因为某种原因响应过慢,下游服务主动停掉一些不太重要的业务,释放出服务器资源,增加响应速度! 不可用:当下游的服务因为某种原因不可用,上游主动调用本地的一些降级逻辑,避免卡顿,迅速返回给用户

  • SpringCloud Zuul实现负载均衡和熔断机制方式

    一.场景 笔者就Zuul网关下实现其负载均衡与熔断机制(雪崩)进行实践,前提是已经导入zuul相关依赖 springboot版本:1.5.9.RELEASE springcloud版本:Dalston.SR5 <dependencies> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-zuul</artif

  • Sentinel熔断规则原理示例详解分析

    目录 概述 熔断(降级)策略 慢调用比例 概念 测试 异常比例 概念 测试 异常数 概念 测试 概述 除了流量控制以外,对调用链路中不稳定的资源进行熔断降级也是保障高可用的重要措施之一. 由于调用关系的复杂性,如果调用链路中的某个资源不稳定,最终会导致请求发生堆积. Sentinel 熔断降级会在调用链路中某个资源出现不稳定状态时(例如调用超时.异常比例升高.异常数堆积) 对这个资源的调用进行限制,让请求快速失败从而避免影响到其它的资源而导致级联错误. 当资源被降级后,在接下来的降级时间窗口之内

  • Sentinel热点规则示例详解分析

    目录 概念 @SentinelResource 小试牛刀 TestController.java defaultFallback fallback 流量控制 熔断降级 热点参数限流 高级选项 概念 商品 ID 为参数,统计一段时间内最常购买的商品 ID 并进行限制 用户 ID 为参数,针对一段时间内频繁访问的用户 ID 进行限制 热点参数限流会统计传入参数中的热点参数,并根据配置的限流阈值与模式,对包含热点参数的资源调用进行限流. 热点参数限流可以看做是一种特殊的流量控制,仅对包含热点参数的资源

  • Kotlin协程Dispatchers原理示例详解

    目录 前置知识 demo startCoroutineCancellable intercepted()函数 DefaultScheduler中找dispatch函数 Runnable传入 Worker线程执行逻辑 小结 前置知识 Kotlin协程不是什么空中阁楼,Kotlin源代码会被编译成class字节码文件,最终会运行到虚拟机中.所以从本质上讲,Kotlin和Java是类似的,都是可以编译产生class的语言,但最终还是会受到虚拟机的限制,它们的代码最终会在虚拟机上的某个线程上被执行. 之

  • C++递归与分治算法原理示例详解

    目录 1. 汉诺塔问题 2. 全排列问题 4. 归并排序 5. 快速排序 6. 棋盘覆盖问题 1. 汉诺塔问题 递归算法,分为 3 步:将 n 个 a 上的盘子借助 c 移动到 b ① 将 n-1 个 a 上的盘子借助 b 移动到 c ② 将 a 上的盘子移动到 b ③ 将 c 上的 n-1 个盘子借助 a 移动到 b 所有盘子都移动到 b 上了 void hanoi(int n,char a,char b,char c)//将n个碟子从a借助c 移到b { if(n==0) return; e

  • Array.reduce使用原理示例详解

    目录 正文 重新了解 Array.reduce reduce 的运用场景 用于计算数据 将多维数组转为一维数组 将函数作为参数 其他场景 最后 正文 我们经常会用到 Array 对象的 reduce 方法,把它用于做一些计算.或者数据组合,发现自己用了那么多年 reduce ,竟然还不是很了解它,最近才发现如果不传递初始值,它也可以正常进行,数组也可以是一个函数数组,来增强我们的代码. 本篇文章将带你重来了解 Array.reduce 和运用场景. 重新了解 Array.reduce 我们来看一

  • java编程FinalReference与Finalizer原理示例详解

    之前写了一篇java编程Reference核心原理示例源码分析的文章,但由于篇幅和时间的原因没有给出FinalReference和Finalizer的分析.同时也没有说明为什么建议不要重写Object#finalize方法(实际上JDK9已经将Object#finalize方法标记为Deprecated).将文章转发到perfma社区后,社区便有同学提出一个有意思的问题?"Object#finalize如果在执行的时候当前对象又被重新赋值,那下次GC就不会再执行finalize方法了,这是为什么

  • Android热修复及插件化原理示例详解

    目录 1.前言 2.类加载机制 3.Android类加载 4.Tinker原理 代码实现 5.插件化 5.1 Activity启动流程简单介绍 5.2 插件化原理 5.2.1 绕开验证 5.2.2还原插件Activity 5.3 加载插件资源 5.3.1 Resources&AssetManager 5.3.2 id冲突 1.前言 热修复一直是这几年来很热门的话题,主流方案大致有两种,一种是微信Tinker的dex文件替换,另一种是阿里的Native层的方法替换.这里重点介绍Tinker的大致原

  • React Fiber 链表操作及原理示例详解

    目录 正文 什么是Fiber Fiber节点React源码 Fiber树是链表 节点独立 节省操作时间与单向操作 利于双缓存与异步可中断更新操作 异步可中断更新 双缓存 正文 看了React源码之后相信大家都会对Fiber有自己不同的见解,而我对Fiber最大的见解就是这玩意儿就是个链表.如果把整个Fiber树当成一个整体确实有点难理解源码,但是如果把它拆开了,将每个节点都看成一个独立单元却能得到一个很清晰的思路,接下来我就简单几点讲讲,我所认为的为什么React要用链表这种数据结构来构建Fib

  • Java并发编程包中atomic的实现原理示例详解

    线程安全: 当多个线程访问某个类时,不管运行时环境采用何种调度方式或者这些进程将如何交替执行,并且在主调代码中不需要任何额外的同步或协调,这个类都能表现出正确的行为,那么就称这个类时线程安全的. 线程安全主要体现在以下三个方面: 原子性:提供了互斥访问,同一时刻只能有一个线程对它进行操作 可见性:一个线程对主内存的修改可以及时的被其他线程观察到 有序性:一个线程观察其他线程中的指令执行顺序,由于指令重排序的存在,该观察结果一般杂乱无序 引子 在多线程的场景中,我们需要保证数据安全,就会考虑同步的

  • Go语言sync.Cond基本使用及原理示例详解

    目录 1. 简介 2. 基本使用 2.1 定义 2.2 方法说明 2.3 使用方式 2.4 使用例子 2.5 为什么Sync.Cond 需要关联一个锁,然后调用Wait方法前需要先获取该锁 3.使用场景 3.1 基本说明 3.2 场景说明 3.2.1 同步和协调多个协程之间共享资源 3.2.2 需要重复唤醒的场景中使用 4. 原理 4.1 基本原理 4.2 实现 4.2.1 Wait方法实现 4.2.2 Singal方法实现 4.2.3 Broadcast方法实现 5.使用注意事项 5.1 调用

随机推荐