Sentinel限流算法总结

走向自由

已于 2025-03-08 11:28:07 修改

阅读量152

点赞数

CC 4.0 BY-SA版权

分类专栏： SpringCloud 文章标签： sentinel java 开发语言

于 2025-01-26 11:31:01 首次发布

原文链接：https://blog.youkuaiyun.com/GBS20200720/article/details/124467146

SpringCloud 专栏收录该内容

4 篇文章

订阅专栏

常见四种限流算法

摘录仅供学习使用，原文大部分内容来源于：Sentinel限流算法详解（硬啃）-优快云博客

1.固定窗口计数器

固定窗口，相比其他的限流算法，这应该是最简单的一种。
它简单地对一个固定的时间窗口内的请求数量进行计数，如果超过请求数量的阈值，将被直接丢弃。
这个简单的限流算法优缺点都很明显。优点的话就是简单，缺点举个例子来说。
比如我们下图中的黄色区域就是固定时间窗口，默认时间范围是 60 秒，限流数量是 100。
如图中括号内所示，前面一段时间都没有流量，刚好后面 30 秒内来了 100 个请求，此时因为没有超过限流阈值，所以请求全部通过，然后下一个窗口的 20 秒内同样通过了 100 个请求。
所以变相的相当于在这个括号的 40 秒的时间内就通过了 200 个请求，超过了我们限流的阈值。

2.滑动窗口计数器

为了优化这个问题，于是有了滑动窗口算法。顾名思义，滑动窗口就是时间窗口在随着时间推移不停地移动。
滑动窗口把一个固定时间窗口再继续拆分成 N 个小窗口，然后对每个小窗口分别进行计数，所有小窗口请求之和不能超过我们设定的限流阈值。
以下图举例子来说：假设我们的窗口拆分成了 3 个小窗口，小窗口都是 20 秒，同样基于上面的例子，当在第三个 20 秒的时候来了 100 个请求，可以通过。
然后时间窗口滑动，下一个 20 秒请求又来了 100 个请求，此时我们滑动窗口的 60 秒范围内请求数量肯定就超过 100 了啊，所以请求被拒绝。

3.漏桶（ Leaky bucket）

漏桶算法名副其实，就是一个漏的桶，不管请求的数量有多少，最终都会以固定的出口流量大小匀速流出。如果请求的流量超过漏桶大小，那么超出的流量将会被丢弃。
也就是说流量流入的速度是不定的，但是流出的速度是恒定的。
这个和 MQ 削峰填谷的思想比较类似，在面对突然激增的流量的时候，通过漏桶算法可以做到匀速排队，固定速度限流。
漏桶算法的优势是匀速，匀速是优点也是缺点，很多人说漏桶不能处理突增流量，这个说法并不准确。
漏桶本来就应该是为了处理间歇性的突增流量。流量一下起来了，然后系统处理不过来，可以在空闲的时候去处理，防止了突增流量导致系统崩溃，保护了系统的稳定性。
但是换一个思路来想，其实这些突增的流量对于系统来说完全没有压力，你还在慢慢地匀速排队，其实是对系统性能的浪费。
所以，对于这种有场景来说，令牌桶算法比漏桶就更有优势。

4.令牌桶（ Token bucket）

令牌桶算法是指系统以一定地速度往令牌桶里丢令牌。当一个请求过来的时候，会去令牌桶里申请一个令牌，如果能够获取到令牌，那么请求就可以正常进行，反之被丢弃。
现在的令牌桶算法，像 Guava 和 Sentinel 的实现都有冷启动 / 预热的方式。为了避免在流量激增

在实际环境中，如果想在初始阶段或隔一段时间系统再次被调用时，有一个预热的过程，即启动时生产令牌的速率慢一些，然后逐步加速，经过预热阶段后达到正常的生产速率，就像车辆的启动阶段，先从1档起步，逐渐加快，2档，3档一直到最快的6档。

RateLimiter.java提供了这种算法的实现。

public static RateLimiter create(
              double permitsPerSecond, 
              long warmupPeriod, 
              TimeUnit unit)

它返回的实现类是SmoothRateLimiter.java类里的内嵌类SmoothWarmingUp。

SmoothWarmingUp的实现原理是怎样的呢，我们看下面的图。

X轴代表令牌桶存储的token数，Y轴代表限流的速率，单位是一个token的生成速率。XY代表了坐标轴围成的矩形面积，也就是（token生产速率）（token数量），它有什么含义呢？是的，它代表了生产n个token的时长，这里使用了积分进行计算。右边的梯型面积表示了热身区的token生产总时长，左下边的长方形面积表示稳定期的token生产时长。我们用一个具体的例子来说明。

RateLimiter limiter = RateLimiter.create(2.0, 4000, MILLISECONDS, 3.0, stopwatch);

这里2.0代表QPS，4000代表warmup为4秒，3.0代表coldFactor即冷却因子，因此

stable interval=1/QPS=1/2=0.5秒=500毫秒，

coldinterval=coldFactor*stable interval=1500毫秒。

通过初始化函数设置令牌桶参数：

@Override
    void doSetRate(double permitsPerSecond, double stableIntervalMicros) {
      double oldMaxPermits = maxPermits;
      double coldIntervalMicros = stableIntervalMicros * coldFactor;
      thresholdPermits = 0.5 * warmupPeriodMicros / stableIntervalMicros;
      maxPermits =
          thresholdPermits + 2.0 * warmupPeriodMicros / (stableIntervalMicros + coldIntervalMicros);
      slope = (coldIntervalMicros - stableIntervalMicros) / (maxPermits - thresholdPermits);
      if (oldMaxPermits == Double.POSITIVE_INFINITY) {
        // if we don't special-case this, we would get storedPermits == NaN, below
        storedPermits = 0.0;
      } else {
        storedPermits =
            (oldMaxPermits == 0.0)
                ? maxPermits // initial state is cold
                : storedPermits * maxPermits / oldMaxPermits;
      }
    }

其中thresholdPermits设置为

thresholdPermits = 0.5 *warmupPeriodMicros /

stableIntervalMicros;

即0.5*4000/500=4，

maxPermits=thresholdPermits +

2.0 * warmupPeriodMicros /

(stableIntervalMicros +coldIntervalMicros);

maxPermits也就是右边梯型的下底，而warmupPeriodMicros是梯形的面积，所以maxPermits是利用梯形的面积公式导出的。而slope表示斜线的斜率，该字段用在计算热身区的token生产时间。初始状态令牌桶处于冷却态，也就是说初始时令牌桶的生产速率最慢，storedPermits等于maxpermits。

当我们从上述的limiter获取令牌时，

for (int i = 0; i < 8; i++) {
            limiter.acquire(); // #1
     }

输出的事件为："R0.00, R1.38, R1.13, R0.88, R0.63, R0.50, R0.50, R0.50"（备注：参考com.google.common.util.concurrent.RateLimiterTest中的testWarmUp方法）。

通过上篇文章我们知道，R代表延迟时间，例如：R0.00代表无延迟获取一个令牌，R1.38代表等待1.38秒获取令牌。

i=0，第一次循环，通过第一篇文章我们知道ratelimiter是寅吃卯粮的思想，因为nextFreeTicketMicros初始值为0，当前时钟也为0，因此延迟为0，生产该token的时间用于下次消费时补偿，也就是右边第一个小梯形的面积。

@Override
    long storedPermitsToWaitTime(double storedPermits, double permitsToTake) {
      double availablePermitsAboveThreshold = storedPermits - thresholdPermits;
      long micros = 0;
      // measuring the integral on the right part of the function (the climbing line)
      if (availablePermitsAboveThreshold > 0.0) {
        double permitsAboveThresholdToTake = min(availablePermitsAboveThreshold, permitsToTake);
        // TODO(cpovirk): Figure out a good name for this variable.
        double length =
            permitsToTime(availablePermitsAboveThreshold)
                + permitsToTime(availablePermitsAboveThreshold - permitsAboveThresholdToTake);
        micros = (long) (permitsAboveThresholdToTake * length / 2.0);
        permitsToTake -= permitsAboveThresholdToTake;
      }
      // measuring the integral on the left part of the function (the horizontal line)
      micros += (long) (stableIntervalMicros * permitsToTake);
      return micros;
}

private double permitsToTime(double permits) {
      return stableIntervalMicros + permits * slope;
    }

availablePermitsAboveThreshold 是储存的大于的threshold的token数量，第一次循环中，

availablePermitsAboveThreshold=maxpermits-threshold=4，

permitsAboveThresholdToTake是申请的token数量，为1，

private double permitsToTime(double permits)用来计算小梯形的上下底的高度，这里permitsToTime(availablePermitsAboveThreshold)获取了下底的高度，permitsToTime(availablePermitsAboveThreshold -

permitsAboveThresholdToTake)是上底的高度，所以

storedPermitsToWaitTime方法就是计算生产token的时间，在存储的token数量大于threshold，即availablePermitsAboveThreshold > 0.0时，计算右边小梯形的面积，这里计算的结果是1.38秒，反之，计算左边小长方形的面积。

i=1，2，3时，重复第二次循环的过程。延迟时间分别对应第2，3，4小梯形的面积，面积递减，分别是1.13，0.88，0.63。

i=4时，由于已经消费了4个token，总时长1.38, 1.13, 0.88, 0.63相加为4.02（由于存在舍入误差，其值不完全等于4），已经过了warmup期，所以进入稳定期，左边的小矩形面积为micros += (long) (stableIntervalMicros * permitsToTake)，高为stableIntervalMicros，0.5秒，permitsToTake为1，即生产时长为0.5秒。

i=5，6，7，8重复上述过程。最后一次循环的生产时长需要后面的申请者偿还。

参考文章：

Sentinel限流算法详解（硬啃）-优快云博客

一文讲解在Sentinel中涉及到的限流算法_sentinel限流算法-优快云博客

令牌桶算法及实现（三） - 简书