sentinel-dashboard 限流、熔断、降级…使用说明记录

sentinel

docker pull bladex/sentinel-dashboard

docker run --name sentinel -d -p 8858:8858 -d bladex/sentinel-dashboard

http://ip:8858

1.限流控制

基本

更正:流控模式中的关联 是 被关联的资源达到阈值,导致当前资源被限流

sentinel-dashboard 限流、熔断、降级…使用说明记录_第1张图片

冷启动

sentinel-dashboard 限流、熔断、降级…使用说明记录_第2张图片

更正:不是请求暴增至预设的阈值开始冷启动,而是感知到有突发的请求同时进入,即开始限流
​ 并缓慢增长至预设的阈值

匀速通过

sentinel-dashboard 限流、熔断、降级…使用说明记录_第3张图片

2.熔断降级

慢比例调用

sentinel-dashboard 限流、熔断、降级…使用说明记录_第4张图片

异常比例

sentinel-dashboard 限流、熔断、降级…使用说明记录_第5张图片

异常数

sentinel-dashboard 限流、熔断、降级…使用说明记录_第6张图片

3.热点限流

sentinel-dashboard 限流、熔断、降级…使用说明记录_第7张图片

第一个参数就是指实际代码中的写的第一个参数

参数例外项

sentinel-dashboard 限流、熔断、降级…使用说明记录_第8张图片

4.系统自适应保护

​ 系统保护规则是从应用级别的入口流量进行控制,从单台机器的总体 Load、RT、入口 QPS 和线程数四个维度监控应用数据,让系统尽可能跑在最大吞吐量的同时保证系统整体的稳定性。

系统保护规则是应用整体维度的,而不是资源维度的,并且仅对入口流量生效

sentinel-dashboard 限流、熔断、降级…使用说明记录_第9张图片

参数说明
  • Load(仅对 Linux/Unix-like 机器生效):当系统 load1 超过阈值,且系统当前的并发线程数超过系统容量时才会触发系统保护。系统容量由系统的 maxQps * minRt 计算得出。设定参考值一般是 CPU cores * 2.5

  • CPU usage(1.5.0+ 版本):当系统 CPU 使用率超过阈值即触发系统保护(取值范围 0.0-1.0)。

  • RT:当单台机器上所有入口流量的平均 RT 达到阈值即触发系统保护,单位是毫秒。

  • 线程数:当单台机器上所有入口流量的并发线程数达到阈值即触发系统保护。

  • 入口 QPS:当单台机器上所有入口流量的 QPS 达到阈值即触发系统保护。

    原理:

    我们把系统处理请求的过程想象为一个水管,到来的请求是往这个水管灌水,当系统处理顺畅的时候,请求不需要排队,直接从水管中穿过,这个请求的RT是最短的;反之,当请求堆积的时候,那么处理请求的时间则会变为:排队时间 + 最短处理时间。

    • 推论一: 如果我们能够保证水管里的水量,能够让水顺畅的流动,则不会增加排队的请求;也就是说,这个时候的系统负载不会进一步恶化。

    我们用 T 来表示(水管内部的水量),用RT来表示请求的处理时间,用P来表示进来的请求数,那么一个请求从进入水管道到从水管出来,这个水管会存在 P * RT 个请求。换一句话来说,当 T ≈ QPS * Avg(RT) 的时候,我们可以认为系统的处理能力和允许进入的请求个数达到了平衡,系统的负载不会进一步恶化。

    接下来的问题是,水管的水位是可以达到了一个平衡点,但是这个平衡点只能保证水管的水位不再继续增高,但是还面临一个问题,就是在达到平衡点之前,这个水管里已经堆积了多少水。如果之前水管的水已经在一个量级了,那么这个时候系统允许通过的水量可能只能缓慢通过,RT会大,之前堆积在水管里的水会滞留;反之,如果之前的水管水位偏低,那么又会浪费了系统的处理能力。

    • 推论二: 当保持入口的流量是水管出来的流量的最大的值的时候,可以最大利用水管的处理能力。

    然而,和 TCP BBR 的不一样的地方在于,还需要用一个系统负载的值(load1)来激发这套机制启动。

    注:这种系统自适应算法对于低 load 的请求,它的效果是一个“兜底”的角色。对于不是应用本身造成的 load 高的情况(如其它进程导致的不稳定的情况),效果不明显。

你可能感兴趣的:(java,阿里巴巴,spring,cloud,云服务)