分布式组件-Sentinel-常见流量控制算法

常见的限流算法

计数器（固定窗口）算法

在指定周期内累加访问次数，当访问次数达到设定的阈值时，触发限流策略，当进入下一个时间周期时进行访问次数的清零。

image.png

限定每一分钟能够处理的总的请求数为100，在第一个一分钟内，一共请求了60次。接着到第二个一分钟，counter又从0开始计数，在一分半钟时，已经达到了最大限流的阈值，这个时候后续的所有请求都会被拒绝。这种算法可以用在短信发送的频次限制上，比如限制同一个用户一分钟之内触发短信发送的次数。

临界问题

这种算法存在一个临界问题，这种算法针对的是固定周期的累加访问次数，但是如果服务器需要做到的是限制每个一分钟内的访问量，这种算法显然就不适用了，因为计数器算法无法限制每隔一段时间内的访问量均不超过阈值。

image.png

在第一分钟的0：58和第二分钟的1：02这个时间段内，分别出现了100个请求，整体来看就会出现4秒内总的请求量达到200，超出了设置的阈值。

滑动窗口算法

滑动窗口算法是将时间周期分为N个小周期（窗口），分别记录每个小周期内访问次数，然后根据时间将窗口往前滑动并删除过期的小时间窗口。最终只需要统计滑动窗口范围内的所有小时间窗口总的计数即可。

image.png

将一分钟拆分为4个小时间窗口，每个小时间窗口最多能够处理25个请求。并且通过虚线框表示滑动窗口的大小（当前窗口的大小是2，也就是在这个窗口内最多能够处理50个请求）。同时滑动窗口会随着时间往前移动，比如前面15s结束之后，窗口会滑动到15s～45s这个范围，然后在新的窗口中重新统计数据。

由此可见，当滑动窗口的格子划分的越多，那么滑动窗口的滚动就越平滑，限流的统计就会越精确。此算法可以很好的解决固定窗口算法的临界问题。

令牌桶限流算法

令牌桶是网络流量整形（Traffic Shaping）和速率限制（Rate Limiting）中最常使用的一种算法。对于每一个请求，都需要从令牌桶中获得一个令牌，如果没有获得令牌，则需要触发限流策略。

image.png

系统会以一个恒定速度（r tokens/sec）往固定容量的令牌桶中放入令牌，如果此时有客户端请求过来，则需要先从令牌桶中拿到令牌以获得访问资格。

限流场景

假设令牌生成速度是每秒10个，也就等同于QPS=10，此时在请求获取令牌的时候，会存在三种情况：

• 请求速度大于令牌生成速度：那么令牌会很快被取完，后续再进来的请求会被限流。

• 请求速度等于令牌生成速度：此时流量处于平稳状态。

• 请求速度小于令牌生成速度：说明此时系统的并发数并不高，请求能被正常处理。

由于令牌桶有固定的大小，当请求速度小于令牌生成速度时，令牌桶会被填满。所以令牌桶能够处理突发流量，也就是在短时间内新增的流量系统能够正常处理，这是令牌桶的特性。

漏桶限流算法

漏桶限流算法的主要作用是控制数据注入网络的速度，平滑网络上的突发流量。

image.png

在漏桶算法内部同样维护一个容器，这个容器会以恒定速度出水，不管上面的水流速度多快，漏桶水滴的流出速度始终保持不变。访问请求到达时直接放入漏桶，如当前容量已达到上限（限流值），则进行丢弃（触发限流策略）。漏桶以固定的速率进行释放访问请求（即请求通过），直到漏桶为空。实际上消息中间件就使用了漏桶限流的思想，不管生产者的请求量有多大，消息的处理能力取决于消费者。

限流场景

在漏桶限流算法中，存在以下几种可能的情况：

• 请求速度大于漏桶流出水滴的速度：也就是请求数超出当前服务所能处理的极限，将会触发限流策略。

• 请求速度小于或者等于漏桶流出水滴的速度，也就是服务端的处理能力正好满足客户端的请求量，将正常执行。

漏桶限流算法和令牌桶限流算法的实现原理相差不大，最大的区别是漏桶无法处理短时间内的突发流量，漏桶限流算法是一种恒定速度的限流算法。

四种算法比较

image.png