Sentinel源码（五）FlowSlot以及限流控制器源码分析

Ethan_199402

已于 2022-02-21 14:46:21 修改

阅读量522

点赞数

分类专栏：源码微服务 springClound 文章标签： java sentinel源码

于 2022-02-20 22:03:42 首次发布

本文链接：https://blog.csdn.net/Ethan_199402/article/details/123035399

版权

源码同时被 3 个专栏收录

20 篇文章 4 订阅

订阅专栏

springClound

17 篇文章 2 订阅

订阅专栏

微服务

15 篇文章 1 订阅

订阅专栏

在Sentinel源码（三）slot解析中，我们遗留了FlowSlot的源码还未分析，本文着重分析，如果没有读过之前文章的同学建议先去了解一下，本文对于基本知识不再阐述

概要

FlowSlot是插槽链的核心：结合从之前的插槽（NodeSelectorSlot、ClusterNodeBuilderSlot 和 StatisticSlot）收集的运行时统计信息，FlowSlot 将使用预先设置的规则来决定是否应该阻止传入的请求。
（插槽链相关知识在本文开头有链接）
通过本类我们知道：
(1)如果触发任何规则，SphU.entry(resourceName)将抛出FlowException。用户可以通过捕获 FlowException}自定义自己的逻辑。
(2) 一个资源可以有多个流规则。 FlowSlot 会遍历这些规则，直到其中一个被触发或所有规则都被遍历完。
(3)每个FlowRule主要由这些因素组成：等级、策略、路径。我们可以结合这些因素来达到不同的效果。


    /**
     * The threshold type of flow control (0: thread count, 1: QPS).
     */
    private int grade = RuleConstant.FLOW_GRADE_QPS;

    /**
     * Flow control threshold count.
     */
    private double count;

    /**
     * Flow control strategy based on invocation chain.
     *
     * {@link RuleConstant#STRATEGY_DIRECT} for direct flow control (by origin);
     * {@link RuleConstant#STRATEGY_RELATE} for relevant flow control (with relevant resource);
     * {@link RuleConstant#STRATEGY_CHAIN} for chain flow control (by entrance resource).
     */
    private int strategy = RuleConstant.STRATEGY_DIRECT;

    /**
     * Reference resource in flow control with relevant resource or context.
     */
    private String refResource;

其中strategy有以下三种

直接拒绝：这是默认行为。超出的请求立即被拒绝并抛出 FlowException
预热：如果系统的负载已经低了一段时间，并且有大量的请求来了，系统可能无法一次处理所有这些请求。但是，如果我们不断增加传入的请求，系统可以预热并最终能够处理所有请求。可以通过在流规则中设置字段warmUpPeriodSec来配置此预热时间。
统一速率限制：该策略严格控制请求之间的间隔。换句话说，它允许请求以稳定、统一的速率通过。该策略是漏桶的实现。它用于以稳定的速率处理请求，并且经常用于突发流量（例如消息处理）。当大量超出系统能力的请求同时到达时，采用这种策略的系统会按照固定的速率处理请求，直到所有请求都被处理完或超时

(5)等级由FlowRule中的 grade 字段定义。0 表示线程隔离，1 表示请求计数整形 (QPS)。线程数和请求数都是在实际运行时收集的，我们可以通过以下命令查看这些统计信息：curl http://localhost:8719/tree
(6)这个阶段通常用于保护资源不被占用。如果资源需要很长时间才能完成，线程将开始占用。响应时间越长，占用的线程就越多。除了计数器，线程池或信号量也可以用来实现这一点。
(7)线程池：分配一个线程池来处理这些资源。当池中没有空闲线程时，请求被拒绝而不影响其他资源。信号量：使用信号量来控制该资源中线程的并发数。
(8) 使用线程池的好处是，它可以在超时时优雅地走开。但它也给我们带来了上下文切换和额外线程的成本。如果传入的请求已经在一个单独的线程中提供服务，例如，一个 Servlet HTTP 请求，如果使用线程池，它将几乎使线程数增加一倍。
(9) 当 QPS 超过阈值时，Sentinel 将采取行动控制传入的请求，由流规则中的 controlBehavior 字段配置。

源码

我们直接来到FlowRuleChecker的canPassCheck方法

public boolean canPassCheck(/*@NonNull*/ FlowRule rule, Context context, DefaultNode node, int acquireCount,
                                                    boolean prioritized) {
        String limitApp = rule.getLimitApp();
        if (limitApp == null) {
            return true;
        }

        if (rule.isClusterMode()) {
            return passClusterCheck(rule, context, node, acquireCount, prioritized);
        }

        return passLocalCheck(rule, context, node, acquireCount, prioritized);
    }

如果是集群模式，通过passClusterCheck检查，否则调用passLocalCheck

passClusterCheck

private static boolean passClusterCheck(FlowRule rule, Context context, DefaultNode node, int acquireCount,
                                            boolean prioritized) {
        try {
            TokenService clusterService = pickClusterService();
            if (clusterService == null) {
                return fallbackToLocalOrPass(rule, context, node, acquireCount, prioritized);
            }
            long flowId = rule.getClusterConfig().getFlowId();
            TokenResult result = clusterService.requestToken(flowId, acquireCount, prioritized);
            return applyTokenResult(result, rule, context, node, acquireCount, prioritized);
            // If client is absent, then fallback to local mode.
        } catch (Throwable ex) {
            RecordLog.warn("[FlowRuleChecker] Request cluster token unexpected failed", ex);
        }
        // Fallback to local flow control when token client or server for this rule is not available.
        // If fallback is not enabled, then directly pass.
        return fallbackToLocalOrPass(rule, context, node, acquireCount, prioritized);
    }

（1）如果passLocalCheck为null，则直接fallback，调用fallbackToLocalOrPass方法

private static boolean fallbackToLocalOrPass(FlowRule rule, Context context, DefaultNode node, int acquireCount,
                                                 boolean prioritized) {
        if (rule.getClusterConfig().isFallbackToLocalWhenFail()) {
            return passLocalCheck(rule, context, node, acquireCount, prioritized);
        } else {
            // The rule won't be activated, just pass.
            return true;
        }
    }

如果读取配置fallbackToLocalWhenFail设置为true，调用passLocalCheck方法继续检查，否则直接返回true无需检查

（2）passLocalCheck不是null，则通过requestToken方法获取
令牌

（2）根据第二步结果判断是否检查通过

private static boolean applyTokenResult(/*@NonNull*/ TokenResult result, FlowRule rule, Context context,
                                                         DefaultNode node,
                                                         int acquireCount, boolean prioritized) {
        switch (result.getStatus()) {
            case TokenResultStatus.OK:
                return true;
            case TokenResultStatus.SHOULD_WAIT:
                // Wait for next tick.
                try {
                    Thread.sleep(result.getWaitInMs());
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                return true;
            case TokenResultStatus.NO_RULE_EXISTS:
            case TokenResultStatus.BAD_REQUEST:
            case TokenResultStatus.FAIL:
            case TokenResultStatus.TOO_MANY_REQUEST:
                return fallbackToLocalOrPass(rule, context, node, acquireCount, prioritized);
            case TokenResultStatus.BLOCKED:
            default:
                return false;
        }
    }

其中shouldwait代表一些高优先级的请求需要占用未来窗口的令牌，所以需要线程休眠waitInMs后在返回true；
如果是下面这些异常情况，会fallback
case TokenResultStatus.NO_RULE_EXISTS:
case TokenResultStatus.BAD_REQUEST:
case TokenResultStatus.FAIL:
case TokenResultStatus.TOO_MANY_REQUEST:
只有在BLOCKED时，会直接返回false，表示检查不通过，需要限流

passLocalCheck

最后看一下passLocalCheck方法

private static boolean passLocalCheck(FlowRule rule, Context context, DefaultNode node, int acquireCount,
                                          boolean prioritized) {
        Node selectedNode = selectNodeByRequesterAndStrategy(rule, context, node);
        if (selectedNode == null) {
            return true;
        }

        return rule.getRater().canPass(selectedNode, acquireCount, prioritized);
    }

（1）根据策略选择node：selectNodeByRequesterAndStrategy

static Node selectNodeByRequesterAndStrategy(/*@NonNull*/ FlowRule rule, Context context, DefaultNode node) {
        // The limit app should not be empty.
        String limitApp = rule.getLimitApp();
        int strategy = rule.getStrategy();
        String origin = context.getOrigin();

        if (limitApp.equals(origin) && filterOrigin(origin)) {
            if (strategy == RuleConstant.STRATEGY_DIRECT) {
                // Matches limit origin, return origin statistic node.
                return context.getOriginNode();
            }

            return selectReferenceNode(rule, context, node);
        } else if (RuleConstant.LIMIT_APP_DEFAULT.equals(limitApp)) {
            if (strategy == RuleConstant.STRATEGY_DIRECT) {
                // Return the cluster node.
                return node.getClusterNode();
            }

            return selectReferenceNode(rule, context, node);
        } else if (RuleConstant.LIMIT_APP_OTHER.equals(limitApp)
            && FlowRuleManager.isOtherOrigin(origin, rule.getResource())) {
            if (strategy == RuleConstant.STRATEGY_DIRECT) {
                return context.getOriginNode();
            }

            return selectReferenceNode(rule, context, node);
        }

        return null;
    }

如果规则配置的限流来源 limitApp 等于当前上下文来源分两种情况：当策略是直接拒绝时，返回originNode；当配置的策略为关联或调用链路则调用selectReferenceNode方法
如果规则配置的限流来源 limitApp 等于 default 时：当策略是直接拒绝时，返回clusterNode（因为没有配置origin和limitApp不需要再根据origin进行区分），当配置的策略为关联或调用链路则调用selectReferenceNode方法
如果规则配置的限流来源 limitApp 等于 other，且当前上下文origin不在流控规则策略中：当策略是直接拒绝时，返回originNode（直接根据origin来进行限流），当配置的策略为关联或调用链路则调用selectReferenceNode方法
selectReferenceNode方法专门为关联资源模式和调用链模式准备

结下来查看selectReferenceNode方法：

static Node selectReferenceNode(FlowRule rule, Context context, DefaultNode node) {
        String refResource = rule.getRefResource();
        int strategy = rule.getStrategy();

        if (StringUtil.isEmpty(refResource)) {
            return null;
        }

        if (strategy == RuleConstant.STRATEGY_RELATE) {
            return ClusterBuilderSlot.getClusterNode(refResource);
        }

        if (strategy == RuleConstant.STRATEGY_CHAIN) {
            if (!refResource.equals(context.getName())) {
                return null;
            }
            return node;
        }
        // No node.
        return null;
    }

先获得关联资源refResource
refResource为null时直接返回null
如果strategy是关联资源，则返回refResource对应的clusterNode
如果strategy是调用链模式：当前上下文名称不是规则配置的name 直接返回null，，否则返回DefaultNode
LimitApp的作用域只在配置的流控策略为RuleConstant.STRATEGY_DIRECT（直接关联）时起作用。其有三种配置，分别为default，origin_name，other
（1） default 如果配置为default，表示统计不区分来源，当前资源的任何来源流量都会被统计（其实就是选择 Node 为 clusterNode 维度）
（2）origin_name 如果配置为指定名称的 origin_name，则只会对当前配置的来源流量做统计
（3）other 如果配置为other 则会对其他全部来源生效但不包括第二条配置的来源
当策略配置为 RuleConstant.STRATEGY_RELATE 或 RuleConstant.STRATEGY_CHAIN 时
STRATEGY_RELATE 关联其他的指定资源，如资源A想以资源B的流量状况来决定是否需要限流，这时资源A规则配置可以使用 STRATEGY_RELATE 策略
STRATEGY_CHAIN 对指定入口的流量限流，因为流量可以有多个不同的入口（EntranceNode）

如果对Node不够理解的可以复习一下之前Sentinel源码（二）入口方法分析中关于Node的知识：

总结一下：配置中不同限流模式其实最终对应的就是选择不同的node进行计算:

直接拒绝模式: 选择cluster node
关联模式: 选择关联resource的cluster node
应用来源: 选择origin node
链路模式: 选择default node

至此获得了策略对应的Node，回到passLocalCheck方法：如果没有node对应为null，则不需要继续检查，否则根据grade继续进行检查

private static boolean passLocalCheck(FlowRule rule, Context context, DefaultNode node, int acquireCount,
                                          boolean prioritized) {
        Node selectedNode = selectNodeByRequesterAndStrategy(rule, context, node);
        if (selectedNode == null) {
            return true;
        }

        return rule.getRater().canPass(selectedNode, acquireCount, prioritized);
    }

查看canPass方法，我们就要学习下一个知识点了------限流控制器

限流控制器

/**
 * class com.alibaba.csp.sentinel.slots.block.flow.FlowRuleUtil
 */
private static TrafficShapingController generateRater(/*@Valid*/ FlowRule rule) {
// 只有Grade为统计 QPS时 才可以选择除默认流控效果外的 其他流控效果控制器
    if (rule.getGrade() == RuleConstant.FLOW_GRADE_QPS) {
        switch (rule.getControlBehavior()) {
        // 预热启动
            case RuleConstant.CONTROL_BEHAVIOR_WARM_UP:
                return new WarmUpController(rule.getCount(), rule.getWarmUpPeriodSec(),
                    ColdFactorProperty.coldFactor);
            // 超过 阈值 排队等待 控制器
            case RuleConstant.CONTROL_BEHAVIOR_RATE_LIMITER:
                return new RateLimiterController(rule.getMaxQueueingTimeMs(), rule.getCount());
            case RuleConstant.CONTROL_BEHAVIOR_WARM_UP_RATE_LIMITER:
            // 上面两个的结合体
                return new WarmUpRateLimiterController(rule.getCount(), rule.getWarmUpPeriodSec(),
                    rule.getMaxQueueingTimeMs(), ColdFactorProperty.coldFactor);
            case RuleConstant.CONTROL_BEHAVIOR_DEFAULT:
            default:
                // Default mode or unknown mode: default traffic shaping controller (fast-reject).
        }
    }
    // 默认控制器 超过 阈值 直接拒绝
    return new DefaultController(rule.getCount(), rule.getGrade());
}

可以比较清晰的看到总共对应有四种流控器的初始化

DefaultController直接拒绝

DefaultController 是默认的，适用于直接拒绝策略，canPass利用滑动时间窗口算法进行流量统计，相关内容请查看Sentinel源码（四）（滑动窗口流量统计）

public boolean canPass(Node node, int acquireCount, boolean prioritized) {
        int curCount = avgUsedTokens(node);
        if (curCount + acquireCount > count) {
            if (prioritized && grade == RuleConstant.FLOW_GRADE_QPS) {
                long currentTime;
                long waitInMs;
                currentTime = TimeUtil.currentTimeMillis();
                waitInMs = node.tryOccupyNext(currentTime, acquireCount, count);
                if (waitInMs < OccupyTimeoutProperty.getOccupyTimeout()) {
                    node.addWaitingRequest(currentTime + waitInMs, acquireCount);
                    node.addOccupiedPass(acquireCount);
                    sleep(waitInMs);

                    // PriorityWaitException indicates that the request will pass after waiting for {@link @waitInMs}.
                    throw new PriorityWaitException(waitInMs);
                }
            }
            return false;
        }
        return true;
    }

RateLimiterController速率限制（排队等待）

排队等待的实现相对预热启动实现比较简单，我们先看排队等候的源码

首先会通过我们的配置，计算出相邻两个请求允许通过的最小时间，然后会记录最近一个通过的时间。两者相加即是下一次请求允许通过的最小时间。

public boolean canPass(Node node, int acquireCount, boolean prioritized) {
        // Pass when acquire count is less or equal than 0.
        if (acquireCount <= 0) {
            return true;
        }
        // Reject when count is less or equal than 0.
        // Otherwise,the costTime will be max of long and waitTime will overflow in some cases.
        if (count <= 0) {
            return false;
        }

        long currentTime = TimeUtil.currentTimeMillis();
        //  计算相邻两个请求 需要相隔多长时间
        long costTime = Math.round(1.0 * (acquireCount) / count * 1000);

        // 本次期望通过的时间
        long expectedTime = costTime + latestPassedTime.get();
		// 如果当前时间大于期望时间，直接通过
        if (expectedTime <= currentTime) {
            // Contention may exist here, but it's okay.
            latestPassedTime.set(currentTime);
            return true;
        } else {
        //当前时间小于期望时间，表示请求太快，需要排队等待指定时间
            // Calculate the time to wait.
            long waitTime = costTime + latestPassedTime.get() - TimeUtil.currentTimeMillis();
            //等待时长大于我们设置的最大时长，则不通过
            if (waitTime > maxQueueingTimeMs) {
                return false;
            } else {
            //更新latestPassedTime
                long oldTime = latestPassedTime.addAndGet(costTime);
                try {
             
                    waitTime = oldTime - TimeUtil.currentTimeMillis();
                    //再此检查（或许在此期间已经通过了别的请求）：等待时长大于我们设置的最大时长，则不通过，并恢复latestPassedTime
                    if (waitTime > maxQueueingTimeMs) {
                        latestPassedTime.addAndGet(-costTime);
                        return false;
                    }
                    // in race condition waitTime may <= 0
                    if (waitTime > 0) {
                        Thread.sleep(waitTime);
                    }
                    return true;
                } catch (InterruptedException e) {
                }
            }
        }
        return false;
    }

latestPassedTime指的是上一次请求通过的时间，通过latestPassedTime + costTime来与当前时间做比较，来判断当前请求是否可以通过
可以通过的请求则会修改latestPassedTime时间，然后sleep到可以通过的时间。
我们也可以配置排队等待的最大时间，来限制目前排队等待通过的请求数量。

注意：latestPassedTime是原子的，不用考虑线程安全问题。但是因为waitTime的第一次检查是在对latestPassedTime做修改之前，在当前请求对latestPassedTime最修改成功之后这段时间，别的请求也会修改latestPassedTime，所以需要第二次检查waitTime不能大于timeoutInMs，类似于DCL双关检索，不直接对代码块加锁是为了提高并发，提高单位时间内处理请求的个数

WarmUpController预热启动

预热是将请求随着时间推移，慢慢增加通过量，防止系统在短时间内，收到比较大的流量冲击，保护系统稳定，防止出现过载等情形。

原理：该控制器限流思想原理思想来自Guava。但是 Guava 的计算是基于 rate 的，这意味着我们需要将 rate 转换为 QPS。但是，Guava 的实现侧重于调整请求间隔，类似于漏桶。 Sentinel 更注重控制每秒传入请求的计数，而不计算其间隔，类似于令牌桶算法。桶中剩余的令牌用于衡量系统效用。假设一个系统每秒可以处理 b 个请求。每隔一秒，b 个令牌就会被添加到桶中，直到桶被填满。当系统处理一个请求时，它会从桶中获取一个令牌。桶中剩余的token越多，系统利用率越低；当令牌桶中的令牌高于某个阈值时，我们称其处于“饱和”状态。基于 Guava 的理论，有一个线性方程，我们可以将其写成 y = mx + b 其中 y（又名 y(x)）或 qps(q)）是给定饱和周期（例如 3分钟），m 是从我们的冷（最小）速率到我们的稳定（最大）速率的变化率，x（或 q）是占用的令牌。

接下看一下构造器：

private void construct(double count, int warmUpPeriodInSec, int coldFactor) {

        if (coldFactor <= 1) {
            throw new IllegalArgumentException("Cold factor should be larger than 1");
        }

        this.count = count;

        this.coldFactor = coldFactor;

        // thresholdPermits = 0.5 * warmupPeriod / stableInterval.
        // warningToken = 100;
         剩余Token的警戒值，小于警戒值系统就进入正常运行期
        warningToken = (int)(warmUpPeriodInSec * count) / (coldFactor - 1);
        // / maxPermits = thresholdPermits + 2 * warmupPeriod /
        // (stableInterval + coldInterval)
        // maxToken = 200
        // 系统最冷时候的剩余Token数
        maxToken = warningToken + (int)(2 * warmUpPeriodInSec * count / (1.0 + coldFactor));

        // slope
        // slope = (coldIntervalMicros - stableIntervalMicros) / (maxPermits
        // - thresholdPermits);
        // 系统预热的速率(斜率)
        slope = (coldFactor - 1.0) / count / (maxToken - warningToken);

    }

首先是构造方法，主要关注2个重要参数

warningToken ：需要警告的令牌数
maxToken 剩余的最大token数，如果剩余token数等于maxToken，则说明系统处于最冷阶段
要理解这两个参数的含义，可以参考令牌桶算法，每通过一个请求，就会从令牌桶中取走一个令牌。那么试想一下，当令牌桶中的令牌达到最大值是，是不是意味着系统目前处于最冷阶段，因为桶里的令牌始终处于一个非常饱和的状态。这里的令牌最大值对应的就是maxToken，而warningToken，则是对应了一个警戒值，当桶中的令牌数减少到一个指定的值时，说明系统已经度过了预热阶段

public boolean canPass(Node node, int acquireCount, boolean prioritized) {
        long passQps = (long) node.passQps();

        long previousQps = (long) node.previousPassQps();
        //计算当前的 剩余 token 数
        syncToken(previousQps);

        // 开始计算它的斜率
        // 如果进入了警戒线，开始调整他的qps
        //如果令牌桶中的token数量大于警戒值，说明还未预热结束，需要判断token的生成速度和消费速度
        long restToken = storedTokens.get();
        if (restToken >= warningToken) {
            long aboveToken = restToken - warningToken;
            // 消耗的速度要比warning快，但是要比慢
            // current interval = restToken*slope+1/count
            //计算此时1s内能够生成token的数量
            double warningQps = Math.nextUp(1.0 / (aboveToken * slope + 1.0 / count));
            //判断token消费速度是否小于生成速度，如果是则正常请求，否则限流
            if (passQps + acquireCount <= warningQps) {
                return true;
            }
        } else {
        //不在预热阶段，则直接判断当前qps是否大于阈值
            if (passQps + acquireCount <= count) {
                return true;
            }
        }

        return false;
    }

该方法中有两个qps，passOps是当前时间的qps，而previousOps可以认为是上一秒的qps

当一个请求进来时，首先需要计算当前桶中剩余的token数，具体逻辑在syncToken方法中
当系统剩余Token大于warningToken时，说明系统仍处于预热阶段，故需要调整当前所能通过的最大qps阈值

protected void syncToken(long passQps) {
        long currentTime = TimeUtil.currentTimeMillis();
        // 获取秒级别时间（去除毫秒）
        currentTime = currentTime - currentTime % 1000;
        long oldLastFillTime = lastFilledTime.get();
        if (currentTime <= oldLastFillTime) {
            return;
        }

        long oldValue = storedTokens.get();
        // 判断是否需要往桶中添加令牌
        long newValue = coolDownTokens(currentTime, passQps);
		// 设置新的token数
        if (storedTokens.compareAndSet(oldValue, newValue)) {
        	// 如果设置成功的话则减去上次通过的qps数量，就得到当前的实际token数
            long currentValue = storedTokens.addAndGet(0 - passQps);
            if (currentValue < 0) {
                storedTokens.set(0L);
            }
            lastFilledTime.set(currentTime);
        }

    }

其中lastFilledTime是记录最近一次更新storeToken的时间的，但是这个有个限制，如果记录的时间与当前时间currentTime是同一秒的，就不会更新storeToken值的。所以简单的理解，storeToken值是按秒数更新的，并且在同一秒内，warningQps的值是一致的，对在同一秒内请求通过的资源是同等对待的

那么，storeToken是如何随着时间推移，慢慢去变化的？
通过coolDownTokens方法得到的新token值，然后storeTokens去重置，并且减去了上一秒的pqs（passQps）更新了lastFilledTime时间，storeTokens剩下部分是认为没有被获取的token值。好，考虑一下，storeToken值的重置，肯定是当前时间与lastFilledTime有关系的，随着时间的推移，storeToken也可能会增多。看一下coolDownTokens方法

private long coolDownTokens(long currentTime, long passQps) {
        long oldValue = storedTokens.get();
        long newValue = oldValue;

        // 添加令牌的判断前提条件:
        // 当令牌的消耗程度远远低于警戒线的时候
        if (oldValue < warningToken) {
            newValue = (long)(oldValue + (currentTime - lastFilledTime.get()) * count / 1000);
        } else if (oldValue > warningToken) {
        //处于预热过程，且消费速度低于冷却速度，则补充令牌
            if (passQps < (int)count / coldFactor) {
                newValue = (long)(oldValue + (currentTime - lastFilledTime.get()) * count / 1000);
            }
        }
        return Math.min(newValue, maxToken);
    }

这里看一下会添加令牌的几种情况

系统初始启动阶段，oldvalue = 0，lastFilledTime也等于0，此时得到一个非常大的newValue，会取maxToken为当前token数量值
系统处于完成预热阶段，需要补充 token 使其稳定在一个范围内（新增间隔时间*配置的qps）
系统处于预热阶段且当前qps小于 count / coldFactor

前2种情况比较好理解，这里主要解释一下第三种情况，为何当前qps小于count / coldFactor时，需要往桶中添加Token？

如果没有这一步在比较低的qps情况下补充Token，系统最终也会慢慢度过预热阶段，但实际上这么低的qps(小于 count / coldFactor时)不应该完成预热。所以这里才会在 qps低于count / coldFactor时补充剩余token数，来让系统在低qps情况下始终处于预热状态下

WarmUpRateLimiterController 预热启动排队等待

预热排队等待，WarmUpRateLimiterController实现类我们发现其继承了WarmUpController，这是Sentinel在1.4版本后新加的一种控制器，其实就是预热启动和排队等待的结合体，具体源码我们就不做分析。

Ethan_199402

关注

0
点赞
踩
3

收藏

觉得还不错? 一键收藏
0
评论
Sentinel源码（五）FlowSlot以及限流控制器源码分析

在Sentinel源码（三）slot解析中，我们遗留了FlowSlot的源码还未分析，本文着重分析，如果没有读过之前文章的同学建议先去了解一下，本文对于基本知识不再阐述概要FlowSlot是插槽链的核心：结合从之前的插槽（NodeSelectorSlot、ClusterNodeBuilderSlot 和 StatisticSlot）收集的运行时统计信息，FlowSlot 将使用预先设置的规则来决定是否应该阻止传入的请求。（插槽链相关知识在本文开头有链接）通过本类我们知道：(1)如果触发任何规则，S
复制链接

扫一扫