前言:为了方便查询相关参数释义,故进行了收集
粘贴gitHub官方解释,部分内容有做补充 https://github.com/alibaba/Sentinel
目录
一、普通限流
二、热点限流
三、系统自适应限流
四、集群限流
一、普通限流
-
resource
:资源名,即限流规则的作用对象 -
count
: 限流阈值 -
grade
: 限流阈值类型(QPS 或并发线程数) -
limitApp
: 流控针对的调用来源,若为default
则不区分调用来源 -
strategy
: 调用关系限流策略 (0(默认)用于直接流量控制,以调用来源origin区分、1 进行相关的流量控制(利用相关资源)、2 用于链流控制(按入口资源)) -
controlBehavior
: 流量控制效果(0、直接拒绝、1、Warm Up、2、匀速排队 3、Warm Up+匀速排队) -
refResource
: 在限流中使用的相关资源或上下文引用资源。 - warmUpPeriodSec:预热时间,默认10s 单位(秒)
- maxQueueingTimeMs:匀速时间,即流量控制效果中匀速排队时间,默认500ms 单位(毫秒)
- clusterMode :是否开启集群限流默认false
- clusterConfig:集群限流相关配置
补充说明:
① limitApp(
根据调用方限流):
ContextUtil.enter(resourceName, origin)
方法中的 origin
参数标明了调用方身份。这些信息会在 ClusterBuilderSlot
中被统计。可通过以下命令来展示不同的调用方对同一个资源的调用数据:
curl http://localhost:8719/origin?id=nodeA
调用数据示例:
id: nodeA
idx origin threadNum passedQps blockedQps totalQps aRt 1m-passed 1m-blocked 1m-total
1 caller1 0 0 0 0 0 0 0 0
2 caller2 0 0 0 0 0 0 0 0
上面这个命令展示了资源名为 nodeA
的资源被两个不同的调用方调用的统计。
流控规则中的 limitApp
字段用于根据调用来源进行流量控制。该字段的值有以下三种选项,分别对应不同的场景:
-
default
:表示不区分调用者,来自任何调用者的请求都将进行限流统计。如果这个资源名的调用总和超过了这条规则定义的阈值,则触发限流。 -
{some_origin_name}
:表示针对特定的调用者,只有来自这个调用者的请求才会进行流量控制。例如NodeA
配置了一条针对调用者caller1
的规则,那么当且仅当来自caller1
对NodeA
的请求才会触发流量控制。 -
other
:表示针对除{some_origin_name}
以外的其余调用方的流量进行流量控制。例如,资源NodeA
配置了一条针对调用者caller1
的限流规则,同时又配置了一条调用者为other
的规则,那么任意来自非caller1
对NodeA
的调用,都不能超过other
这条规则定义的阈值。
同一个资源名可以配置多条规则,规则的生效顺序为:{some_origin_name} > other > default
②
根据调用链路入口限流:链路限流:
NodeSelectorSlot
中记录了资源之间的调用链路,这些资源通过调用关系,相互之间构成一棵调用树。这棵树的根节点是一个名字为 machine-root
的虚拟节点,调用链的入口都是这个虚节点的子节点。
一棵典型的调用树如下图所示:
machine-root
/ \
/ \
Entrance1 Entrance2
/ \
/ \
DefaultNode(nodeA) DefaultNode(nodeA)
上图中来自入口 Entrance1
和 Entrance2
的请求都调用到了资源 NodeA
,Sentinel 允许只根据某个入口的统计信息对资源限流。比如我们可以设置 strategy
为 RuleConstant.STRATEGY_CHAIN
,同时设置 refResource
为 Entrance1
来表示只有从入口 Entrance1
的调用才会记录到 NodeA
的限流统计当中,而不关心经 Entrance2
到来的调用。
调用链的入口(上下文)是通过 API 方法 ContextUtil.enter(contextName)
定义的,其中 contextName 即对应调用链路入口名称。详情可以参考 ContextUtil 文档。
③ strategy
(具有关系的资源流量控制:关联流量控制):
当两个资源之间具有资源争抢或者依赖关系的时候,这两个资源便具有了关联。比如对数据库同一个字段的读操作和写操作存在争抢,读的速度过高会影响写得速度,写的速度过高会影响读的速度。如果放任读写操作争抢资源,则争抢本身带来的开销会降低整体的吞吐量。可使用关联限流来避免具有关联关系的资源之间过度的争抢,举例来说,read_db
和 write_db
这两个资源分别代表数据库读写,我们可以给 read_db
设置限流规则来达到写优先的目的:
设置 strategy
为 RuleConstant.STRATEGY_RELATE
(此说明为Java中常量,值对标为1)同时设置 refResource
为 write_db
。这样当写库操作过于频繁时,读数据的请求会被限流。
二、热点限流
-
resource
:资源名,即限流规则的作用对象 -
count
: 限流阈值 -
grade
: 限流阈值类型(QPS 或并发线程数) - durationInSec:统计窗口时间长度(单位秒)默认1s统计一次,即每1s限制配置的count值 1.6.0版本开始支持
-
controlBehavior
: 流量控制效果(0、直接拒绝、1、Warm Up、2、匀速排队 3、Warm Up+匀速排队) - maxQueueingTimeMs: 匀速时间,即流量控制效果中匀速排队时间,默认500ms 单位(毫秒)1.6.0版本开始支持
- paramIdx:热点参数的索引,必填(对应方法参数下标,从0开始)
- paramFlowItemList:参数例外项,可以针对指定的参数值单独设置限流阈值,不受前面
count
阈值的限制。仅支持基本类型和字符串类型 - clusterMode :是否开启集群限流默认false
- clusterConfig:集群限流相关配置
三、系统自适应限流
以下参数皆默认为-1 不开启
- highestSystemLoad:
load1
触发值,用于触发自适应控制阶段 (load值参考为linux的 load average 注:仅unix和linux系统有效) - avgRt: 所有入口流量的平均响应时间
- maxThread: 入口流量的最大并发数
- qps:所有入口资源的 QPS (机器角度所有web请求)
- highestCpuUsage:当前系统的 CPU 使用率(0.0-1.0)
四、集群限流
-
flowId
:(必需)全局唯一的规则 ID,由集群限流管控端分配 (Long类型) -
thresholdType
: 阈值模式,默认(0)为单机均摊,1 为全局阈值 - strategy :目前官方没给出解释,源码部分的注释也为空 仅有0,1两个值 看源码1.7.1的内容大概为0的时候不会进行限流,为其他任何值都会进行限流,默认为0
- fallbackToLocalWhenFail :在 client 连接tokenServer失败或通信失败时,是否退化到本地的限流模式 默认为true