Sentinel的限流和GateWay的限流有什么差别（算法）

目录

固定窗口算法

 滑动窗口算法

令牌桶算法（Token bucket） 

漏桶算法

 Sentinel的限流与Gateway的限流有什么差别？

---

这里涉及四种算法

固定窗口算法

 介绍：在指定周期内访问次数达到阈值就会触发限流策略，到下一周期进行清零重新计数

 问题：通常用于QPS限流（一次访问数）和统计总访问量，对于秒级以上的时间周期来说，会存在一个非常严重的问题，那就是临界问题

我们可以在两个周期内算一个周期，也就是说这里前面都没有流量，刚好后面20s来60请求，没有超过阈值故通过，然后再第二个周期前20s来60ge也没有超过阈值所以通过，但是这两个20s加起来就超过阈值了

 滑动窗口算法

介绍：就是时间窗口随着时间的推移不断移动，滑动窗口把一个固定的窗口进行拆分为N个小窗口，然后对小窗口分别计数，小窗口请求之和不能超过我们设定的限流阈值

例子：

假设我们的窗口拆分成了 3 个小窗口，小窗口都是 20 秒，同样基于上面的例子，当在第三个 20 秒的时候来了 100 个请求，可以通过；

然后时间窗口滑动，下一个 20 秒请求又来了 100 个请求，此时我们滑动窗口的 60 秒范围内请求数量肯定就超过 100 了啊，所以请求被拒绝。

令牌桶算法（Token bucket） 

介绍：指的是以一定速度往令牌桶里面丢令牌。当请求过来的时候，先会去往令牌桶里申请一个令牌，如果能获取令牌那请求就正常执行；

现在的令牌桶算法，像 Guava 和 Sentinel 的实现都有冷启动 / 预热的方式。为了避免在流量激增的同时把系统打挂，令牌桶算法会在最开始一段时间内冷启动，随着流量的增加，系统会根据流量大小动态地调整生成令牌的速度，直到最终请求达到系统阈值。（有点类似于warm up）

如每100毫秒往桶里加入1000毫升的水，如果桶已经满了就不再加了（说明：令牌桶算法和漏桶算法相反，漏桶算法是按照客户请求的数量往漏桶中加水的，而令牌桶算法是服务器端控制往桶里加水的）。当有新请求来临时,会各自从桶里拿走一个令牌,如果没有令牌可拿了就阻塞或者拒绝服务

 优点：服务端可以根据实际服务性能来控制生成令牌的速度和水桶容量， 一旦需要提高速率,则按需提高放入桶中的令牌的速率；但是请求去拿令牌是没有速度限制的，说明不是平稳运行的，可以一下短时间拿很多令牌，令牌桶拿不到令牌被拒绝；

漏桶算法

介绍：首先请求以不确定的速度进入漏桶，然后漏桶以一定速度出水，（当请求过大，也就是水流速度过大）会导致直接溢出，然后拒绝请求；可以看出漏桶算法能强行限制数据的传输速率。因此漏桶算法在这方面比滑动窗口而言，更加先进。

从图片可知，漏桶算法需要设定两个参数，一个是桶的容量大小（决定可以存放多少个请求），然后就是水桶漏出来的速度（决定单位时间内向服务器请求的平均次数）

 Sentinel的限流与Gateway的限流有什么差别？

限流算法常见的有三种实现：滑动时间窗口、令牌桶算法、漏桶算法。

Gateway则采用了基于Redis实现的令牌桶算法：由服务端决定生成token的速度，然后请求从令牌桶中获取token，这里面有个类似于Sentinel中流控效果中的warm up，生成token的速度会慢慢递增防止请求一下增大打死服务器

Sentinel中：

默认限流是滑动窗口算法

排队等待是漏桶算法

热点参数限流是令牌桶算法

(36条消息) Sentinel_Fairy要carry的博客-CSDN博客_sentinel降级规则