一、概述

FlowSlot 会根据预设的规则，结合前面 NodeSelectorSlot、ClusterNodeBuilderSlot、StatistcSlot 统计出来的实时信息进行流量控制。

限流的直接表现是在执行 Entry nodeA = SphU.entry(资源名字) 的时候抛出 FlowException 异常。FlowException 是 BlockException 的子类，您可以捕捉 BlockException 来自定义被限流之后的处理逻辑。

同一个资源可以对应多条限流规则。FlowSlot 会对该资源的所有限流规则依次遍历，直到有规则触发限流或者所有规则遍历完毕。

二、定义流量控制规则

流量规则包含下面几个重要的属性：

同一个资源可以同时有多个限流规则。

具体的 FlowRule 可以用下面这张图表示：

2.1 grade 流量控制阈值类型

流量控制主要有两种统计类型，一种是统计线程数，另外一种则是统计 QPS。类型由 FlowRule.grade 字段来定义。其中，0 代表根据并发数量来限流，1 代表根据 QPS 来进行流量控制。线程数、QPS 值，都是由 StatisticSlot 实时统计获取的。

• QPS流量控制

  当 QPS 超过某个阈值的时候，则采取措施进行流量控制。

• 并发线程数流量控制

  线程数限流用于保护业务线程数不被耗尽。

  例如，当应用所依赖的下游应用由于某种原因导致服务不稳定、响应延迟增加，对于调用者来说，意味着吞吐量下降和更多的线程数占用，极端情况下甚至导致线程池耗尽。

  为应对高线程占用的情况，业内有使用隔离的方案，比如通过不同业务逻辑使用不同线程池来隔离业务自身之间的资源争抢（线程池隔离），或者使用信号量来控制同时请求的个数（信号量隔离）。

  这种隔离方案虽然能够控制线程数量，但无法控制请求排队时间。当请求过多时排队也是无益的，直接拒绝能够迅速降低系统压力。Sentinel线程数限流不负责创建和管理线程池，而是简单统计当前请求上下文的线程个数，如果超出阈值，新的请求会被立即拒绝。

2.2 controlBehavior 流量控制手段

流量控制的手段包括下面 3 种，对应 FlowRule 中的 controlBehavior 字段：

• RuleConstant.CONTROL_BEHAVIOR_DEFAULT（默认）

  直接拒绝方式。

  当QPS超过任意规则的阈值后，新的请求就会被立即拒绝，拒绝方式为抛出FlowException。这种方式适用于对系统处理能力确切已知的情况下，比如通过压测确定了系统的准确水位时。

• RuleConstant.CONTROL_BEHAVIOR_WARM_UP

  冷启动方式。

  该方式主要用于系统长期处于低水位的情况下，当流量突然增加时，直接把系统拉升到高水位可能瞬间把系统压垮。通过"冷启动"，让通过的流量缓慢增加，在一定时间内逐渐增加到阈值上限，给冷系统一个预热的时间，避免冷系统被压垮的情况。

• RuleConstant.CONTROL_BEHAVIOR_RATE_LIMITER

  匀速器方式。

  这种方式严格控制了请求通过的间隔时间，也即是让请求以均匀的速度通过，对应的是漏桶算法。具体

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

2.3 基于调用关系的流量控制

调用关系包括调用方、被调用方。方法又可能会调用其它方法，形成一个调用链路的层次关系。

Sentinel 通过 NodeSelectorSlot 建立不同资源间的调用的关系，并且通过 ClusterNodeBuilderSlot 记录每个资源的实时统计信息。

有了调用链路的统计信息，我们可以衍生出多种流量控制手段。

2.3.1 limitApp 基于调用方进行流量控制

在ContextUtil.enter(resourceName, origin) 方法中的 origin 参数标明了调用方身份。这些信息会在 ClusterBuilderSlot 中被统计。

限流规则中的 limitApp 字段用于根据不同调用方进行流量控制。该字段的值有以下三种选项，分别对应不同场景：

• default（默认）

  表示不区分调用者，来自任何调用者的请求都将进行限流统计。

  如果这个资源名的调用总和超过了这条规则定义的阈值，则触发限流。

• {some_origin_name}

  表示针对特定的调用者，只有来自这个调用者的请求才会进行流量控制。

  例如 ，资源NodeA 配置了一条针对调用者caller1的规则，那么当且仅当来自 caller1 对 NodeA 的请求才会触发流量控制。

• other

  表示针对除 {some_origin_name} 以外的其余调用方的流量进行流量控制。

  例如，资源NodeA配置了一条针对调用者 caller1 的限流规则，同时又配置了一条调用者为 other 的规则，那么任意来自非 caller1 对 NodeA 的调用，都不能超过 other 这条规则定义的阈值。

同一个资源名可以配置多条规则，规则的生效顺序为：{some_origin_name} > other > default

2.3.2 strategy 基于调用关系的流量控制

基于调用关系的流量控制，有三种情况可以选择：

• STRATEGY_DIRECT（默认）

  根据调用方进行限流。ContextUtil.enter(resourceName, origin) 方法中的 origin 参数标明了调用方的身份。

  如果 strategy 选择了DIRECT ，则还需要结合流量控制规则中的 limitApp 字段，根据不同调用方在不同场景中进行流量控制。

• STRATEGY_CHAIN

  根据调用链路入口限流。

  NodeSelectorSlot 中记录了资源之间的调用链路，这些资源通过调用关系，相互之间构成一棵调用树。这棵树的根节点是一个名字为 machine-root 的虚拟节点，调用链的入口都是这个虚节点的子节点。

  一棵典型的调用树如下图所示：

   	          machine-root/       \/         \Entrance1     Entrance2/             \/               \DefaultNode(nodeA)   DefaultNode(nodeA)
  

  上图中来自入口 Entrance1 和 Entrance2 的请求都调用到了资源 NodeA，Sentinel 允许只根据某个入口的统计信息对资源限流。比如我们可以设置 FlowRule.strategy 为 RuleConstant.CHAIN，同时设置 FlowRule.refResource 为 Entrance1 来表示只有从入口 Entrance1 的调用才会记录到 NodeA 的限流统计当中，而对来自 Entrance2 的调用漠不关心。

  调用链的入口是通过 API 方法 ContextUtil.enter(name) 定义的。

• STRATEGY_RELATE

  基于关联流量控制。当两个资源之间具有资源争抢或者依赖关系的时候，这两个资源便具有了关联。可使用关联限流来避免具有关联关系的资源之间过度的争抢。

  比如对数据库同一个字段的读操作和写操作存在争抢，读的速度过高会影响写得速度，写的速度过高会影响读的速度。如果放任读写操作争抢资源，则争抢本身带来的开销会降低整体的吞吐量。可使用关联限流来避免具有关联关系的资源之间过度的争抢。

  举例来说，read_db 和 write_db 这两个资源分别代表数据库读写，我们可以给 read_db 设置限流规则来达到写优先的目的：设置 FlowRule.strategy 为 RuleConstant.RELATE 同时设置 FlowRule.refResource 为 write_db。这样当写库操作过于频繁时，读数据的请求会被限流。