Skip to content

流量控制

Jump to bottom
louyuting edited this page Sep 26, 2020 · 17 revisions

Overview

流量控制(flow control)，其原理是监控资源(Resource)的QPS或则其余统计指标，然后根据Token计算策略来计算资源的可用token(也就是阈值)，然后根据流量控制策略对流量进行控制，避免被瞬时的流量高峰冲垮，从而保障应用的高可用性。

Sentinel的流量控制实现代码参考：https://github.com/alibaba/sentinel-golang/tree/master/core/flow

Sentinel 通过定义流控规则来实现对 resource 的流量控制。在 Sentinel 内部会在加载规则时候将每个 flow.Rule 都会被转换成流量控制器TrafficShapingController。 每个TrafficShapingController 实例都会有独立的统计结构，这里统计结构也是一个滑动窗口，Sentinel 内部会尽可能复用 resource 级别的全局滑动窗口，如果rule的统计设置没法复用resource的全局统计结构，那么Sentinel会为 TrafficShapingController 创建一个全新的滑动窗口，然后通过 flow.StandaloneStatSlot 来维护统计。

Sentinel的流量控制组件对资源的控制结果要么通过，要么会block，对于block的流量相当于拒绝。

流控规则

流控规则的定义如下, flow.Rule

type Rule struct {
	// ID represents the unique ID of the rule (optional).
	ID string `json:"id,omitempty"`
	// Resource represents the resource name.
	Resource               string                 `json:"resource"`
	TokenCalculateStrategy TokenCalculateStrategy `json:"tokenCalculateStrategy"`
	ControlBehavior        ControlBehavior        `json:"controlBehavior"`
	// Threshold means the threshold during StatIntervalInMs
	// If StatIntervalInMs is 1000(1 second), Threshold means QPS
	Threshold         float64          `json:"threshold"`
	RelationStrategy  RelationStrategy `json:"relationStrategy"`
	RefResource       string           `json:"refResource"`
	MaxQueueingTimeMs uint32           `json:"maxQueueingTimeMs"`
	WarmUpPeriodSec   uint32           `json:"warmUpPeriodSec"`
	WarmUpColdFactor  uint32           `json:"warmUpColdFactor"`
	// StatIntervalInMs indicates the statistic interval and it's the optional setting for flow Rule.
	// If user doesn't set StatIntervalInMs, that means using default metric statistic of resource.
	// If the StatIntervalInMs user specifies can not reuse the global statistic of resource,
	// 		sentinel will generate independent statistic structure for this rule.
	StatIntervalInMs uint32 `json:"statIntervalInMs"`
}

一条流控规则主要由下面几个因素组成，我们可以组合这些元素来实现不同的限流效果：

  • Resource：资源名，即规则的作用目标。
  • TokenCalculateStrategy: 当前流量控制器的Token计算策略。Direct表示直接使用字段 Threshold 作为阈值；WarmUp表示使用预热方式计算Token的阈值。
  • ControlBehavior: 表示流量控制器的控制策略；Reject表示超过阈值直接拒绝，Throttling表示匀速排队。
  • Threshold: 表示流控阈值；如果字段 StatIntervalInMs 是1000(也就是1秒)，那么Threshold就表示QPS，流量控制器也就会依据资源的QPS来做流控。
  • RelationStrategy: 调用关系限流策略，CurrentResource表示使用当前规则的resource做流控；AssociatedResource表示使用关联的resource做流控，关联的resource在字段 RefResource 定义；
  • RefResource: 关联的resource；
  • WarmUpPeriodSec: 预热的时间长度，该字段仅仅对 WarmUp 的TokenCalculateStrategy生效；
  • WarmUpColdFactor: 预热的因子，默认是3，该值的设置会影响预热的速度，该字段仅仅对 WarmUp 的TokenCalculateStrategy生效；
  • MaxQueueingTimeMs: 匀速排队的最大等待时间，该字段仅仅对 Throttling ControlBehavior生效；
  • StatIntervalInMs: 规则对应的流量控制器的独立统计结构的统计周期。如果StatIntervalInMs是1000，也就是统计QPS。

流量控制策略

Sentinel的流量控制策略由规则中的 TokenCalculateStrategy 和 ControlBehavior 两个字段决定。TokenCalculateStrategy 表示流量控制器的Token计算方式，目前Sentinel支持两种：

  1. Direct表示直接使用规则中的 Threshold 表示当前统计周期内的最大Token数量。
  2. WarmUp表示通过预热的方式计算当前统计周期内的最大Token数量，预热的计算方式会根据规则中的字段 WarmUpPeriodSec 和 WarmUpColdFactor 来决定预热的曲线。

WarmUp方式，即预热/冷启动方式。当系统长期处于低水位的情况下，当流量突然增加时，直接把系统拉升到高水位可能瞬间把系统压垮。通过"冷启动"，让通过的流量缓慢增加，在一定时间内逐渐增加到阈值上限，给冷系统一个预热的时间，避免冷系统被压垮。这块设计和Java类似，可以参考限流 冷启动 通常冷启动的过程系统允许通过的 QPS 曲线如下图所示：

字段ControlBehavior表示表示流量控制器的控制行为，目前Sentinel支持两种：

  1. Reject：表示如果当前统计周期内，统计结构统计的请求数超过了阈值，就直接拒绝。
  2. Throttling：表示匀速排队的统计策略。它的中心思想是，以固定的间隔时间让请求通过。当请求到来的时候，如果当前请求距离上个通过的请求通过的时间间隔不小于预设值，则让当前请求通过；否则，计算当前请求的预期通过时间，如果该请求的预期通过时间小于规则预设的 timeout 时间，则该请求会等待直到预设时间到来通过（排队等待处理）；若预期的通过时间超出最大排队时长，则直接拒接这个请求。

匀速排队方式会严格控制请求通过的间隔时间，也即是让请求以均匀的速度通过，对应的是漏桶算法。该方式的作用如下图所示：

这种方式主要用于处理间隔性突发的流量，例如消息队列。想象一下这样的场景，在某一秒有大量的请求到来，而接下来的几秒则处于空闲状态，我们希望系统能够在接下来的空闲期间逐渐处理这些请求，而不是在第一秒直接拒绝多余的请求。

以下规则代表每 100ms 最多通过一个请求，多余的请求将会排队等待通过，若排队时队列长度大于 500ms 则直接拒绝：

{
	Resource:          "some-test",
	MetricType:        flow.QPS,
	Count:             10, // 请求的间隔控制在 1000/10=100 ms
        TokenCalculateStrategy: flow.Direct,
	ControlBehavior:   flow.Throttling, // 流控效果为匀速排队
	MaxQueueingTimeMs: 500, // 最长排队等待时间
}

MaxQueueingTimeMs 设为 0 时代表不允许排队，只控制请求时间间隔，多余的请求将会直接拒绝。

流量控制器的统计结构

每个流量控制器的实例都会有自己独立的统计结构。流量控制器的统计结构由规则的 StatIntervalInMs 字段设置，StatIntervalInMs字段表示统计结构的统计周期。Sentinel 默认会为每个resource创建一个全局的滑动窗口统计结构，这个全局的统计结构默认是一个间隔为10s,20个格子的滑动窗口，也就是每个统计窗口长度是500ms。

每个流量控制器会尽可能复用这个resource级别的全局统计结构。复用的逻辑是这样：

  1. 如果StatIntervalInMs大于全局滑动窗口的间隔(默认10s)，那么将不可复用全局统计结构。Sentinel会给流量控制器创建一个长度是StatIntervalInMs，格子数是1的全新统计结构，这个全新的统计结构由Sentinel内部的StandaloneStatSlot来维护统计。
  2. 如果StatIntervalInMs小于全局滑动窗口的窗口长度(默认是500ms), 那么将不可复用全局统计结构。Sentinel会给流量控制器创建一个长度是StatIntervalInMs，格子数是1的全新统计结构，这个全新的统计结构由Sentinel内部的StandaloneStatSlot来维护统计。
  3. 如果StatIntervalInMs在集合[全局滑动窗口的窗口长度，全局滑动窗口的间隔]之间，首先需要计算格子数：如果StatIntervalInMs可以被全局滑动窗口的窗口长度(默认是500ms)整除，那么格子数就为 StatIntervalInMs/GlobalStatisticBucketLengthInMs，如果不可整除，格子数是1。然后会调用 core/base/CheckValidityForReuseStatistic函数来判断当前统计结构间隔和格子数是否可以复用全局统计结构。如果可以复用，就会基于resource级别的全局统计结构ResourceNode创建SlidingWindow，SlidingWindow是一个虚拟结构，SlidingWindow只可读，而且读的数据是通过聚合ResourceNode数据得到的。如果不可复用，就使用统计结构间隔和格子数创建全新的滑动窗口(BucketLeapArray)。

CheckValidityForReuseStatistic函数参考：https://github.com/alibaba/sentinel-golang/blob/master/core/base/stat.go#func CheckValidityForReuseStatistic

基于规则创建统计结构的逻辑参考：https://github.com/alibaba/sentinel-golang/blob/master/core/flow/rule_manager.go#func generateStatFor

基于调用关系的流量控制

Sentinel 支持关联流量控制策略。当两个资源之间具有资源争抢或者依赖关系的时候，这两个资源便具有了关联。比如对数据库同一个字段的读操作和写操作存在争抢，读的速度过高会影响写得速度，写的速度过高会影响读的速度。如果放任读写操作争抢资源，则争抢本身带来的开销会降低整体的吞吐量。可使用关联限流来避免具有关联关系的资源之间过度的争抢。

核心接口

在流控模块（flow）中，Sentinel 会为每条流控规则（flow.Rule）生成相应的流量调配器（TrafficShapingController）。TrafficShapingController 由两部分构成：

  • TrafficShapingCalculator: 根据规则的计算策略计算出当前的流量阈值（如部分策略在一段时间内逐步抬升 QPS 阈值）
  • TrafficShapingChecker: 根据阈值执行相应的检查和调配策略，返回 base.TokenResult 指示如何进行调配。

常见场景的规则配置：

1.基于QPS对某个资源限流

2.资源的流量存在脉冲曲线走势

3.基于一定统计间隔时间来控制总的请求数

Clone this wiki locally