SpringCloud Alibaba Sentinel 与 SpringCloud Gateway 的限流有什么差别？(三种限流算法原理分析)

例如，时间窗口大小是 1000ms，分区是 500ms，qps 是 3.? 假设有三个请求，分别是 900ms、 1250ms、1300 ms，此时计算窗口大小就是 1300ms ~ 1300ms - 1000ms 的下一个时区，也就是? 500 ~ 1500ms，一共有三个请求.? 如果400ms 又来了一个请求，是不是按照滑动窗口的计算方式就超出了，因此就会抛弃掉.

但是如果按照固定窗口大小计算，就有可能正好在 500 ~ 1500ms 这个区间也是一秒，因此就会放行通过，那这就相当于多放行了一个请求！

那么滑动窗口就一定没问题么？

不一定哦，假设 1600ms 这个时候又来了一个请求，就要出问题了！乍一看，窗口区间是 1600ms ~ 1600ms - 1000ms 的下一个时区，也就是 1600ms ~ 1000ms，只放行了三个请求.

但是仔细看一下，1600ms 和 900ms 的这个请求之间差多少秒？是不是 700ms，也就是说，这700ms 的时间，连续放行了 4 个请求！

因此，滑动窗口知识解决了固定窗口的小问题，而如果几个请求之在窗口之间挨的很近，依然会出问题.? 这个时候，你就可以把这个时区再继续分的更细一点，就能解决了.? ?例如时区大小是 250ms，那么窗口区间就是 1600ms ~ 750ms，而此时一看窗口里面有 4 个请求，就会把最后来的请求给抛弃了~

如下图：

1.1.3、令牌桶算法

a）令牌桶算法就说，有一个桶，这个桶里会以固定的速率去生成令牌（这个速率实际上就是 qps）.

b）当这个桶满了以后，就会把多余的令牌丢弃.

c）每一个请求来的时候都会去申请一个令牌，如果桶中没有令牌，请求就会被丢弃.

例如，qps 是5，也就是生成令牌的速率是每秒 5 个，而此时桶中有 5 个令牌，但是忽然有 6 个请求同时到来，那么多出来的请求就会被丢掉.

令牌桶算法的缺陷：

思考这样一个问题，假设桶的容量是 5，每秒生成 5 个令牌，但非常神奇的是，第一秒的时候一个请求都没有来，而第二秒突然来了 10 个请求，那么首先会先去桶里把存的 5 个令牌拿走，这 5 个请求瞬间就过去了，而第二秒的时候又要生成 5 个令牌，剩下的 5 个令牌是不是也能过去.

这就超过阈值了...

他的缺陷同时也是一个好处：

如果我们设置令牌的速度不是我们服务器的上限，而是一个平均值，偶尔超出也不会把服务压垮，那么令牌桶就可以很好的处理突发的请求情况（请求带有波动性的）.

例如服务器的最大并发能力是 6，我设置 qps 为 3（令牌生成速度），如果说第一秒没有请求来，那么第二秒的时候来了 6 个请求，此时就可以桶里有 6 个令牌，就都能都放行处理了，不会造成请求的丢失.

令牌桶的真正底层实现：

虽然我们讲他是利用一个桶，每秒钟生成多少令牌，但是代码真正的实现可不是这样，因为你还要弄个定时器去生成，很麻烦.

令牌桶的代码实现思路是这样的：

这个桶的话实际上里面并不会生成令牌，而是记录上一个请求来的时间，另外还记录了当前还有几个令牌了.
只要记录了这两样东西，那么当请求来了以后，我只需要计算这个请求和上一个请求之间的时间差，如果时间差在小于令牌在这段时间生成的数量，就可以放行通过

例如我每秒生成 5 个令牌，那么假设来了两个请求，我就可以计算以下他两的时间差，比如说是 0.2 秒，那么当前的令牌个数就可以认为是 0.2 * 5 = 1，因此此时只有一个令牌，只能处理一个请求，处理不了这第二个.

1.1.4、漏桶算法

a）漏桶算法呢也有一个桶，只不过不是用来存令牌的，而是用来存请求的.

b）当请求来了，就会把它当成一滴水放到桶里面去，然后漏桶就会以固定的速率向漏出请求.

c）如果桶满了，多余的请求就会被丢弃.

这就像是有一个桶，但是桶下面开了一个小口，当你往桶里倒水的时候，水就会以固定的速率从这个固定大小的小口流出.

漏桶算法的优势：

应对突发的请求：假如漏桶的处理速度是每 3s 一个请求，但是如果突发来了 10 个请求，没关系，我在桶里先存起来，后面慢慢处理就可以.
流量永远是平滑的：不管你每秒是来了 10 个还是 100 个请求，只要我桶够大，那么放出去的速度永远都是固定的，也就是说他处理请求的速度一直是一条直线.
对比令牌桶：对于令牌桶来说，如果请求忽高忽低，这个时候令牌桶就没办法保证平滑，他有可能会出现忽高忽低的情况，因为前一秒令牌没有用完可以累计，在下一秒就有可能出现一次性被消耗完的情况.

漏桶算法的实现原理：

a）漏桶算法的请求实际上就是遵循先进先出，那么用的容器肯定就是队列.

b）当请求来的时候，这些请求就会按照时间间隔依次执行.

c）并且会有一个预期等待时间，实际上就是桶的大小.? 当新的请求到来时，就会将桶中所有请求的等待时间加起来，然后再加上新的请求，如果大于预期等待时间，这个新的请求就会被抛弃.

例如，桶的预期等待时间是 2000ms（桶的大小），qps 是 5（每秒通过 5 个请求），也就相当于 200ms 处理一个请求.

突然某一时刻同时来了很多请求，那么第一个请求进来时，可以立即被执行，因此等待时间就是 0ms，第二请求就需要排队了，就是 200ms 的时候会被执行，往后以此类推.? ?当队列中所有请求的等待时间加起来等于 2000ms 的时候（预期等待时间），此时再来的请求就会被拒绝.

1.2、解决问题

明白上述的四种算法，回答这个问题就游刃有余了~

这个时候你就可以说，那么首先呢常见的有 3 种限流算法，分别是计数器算法、令牌桶算法、漏桶算法.? Gateway 采用的是基于 Redis 实现的令牌桶算法（key value 就是一个桶）.

而 Sentinel 内部实现的比较复杂：

默认限流模式是基于滑动时间窗口算法
排队等待的限流模式则基于漏桶算法：因为漏桶算法本身就是一种排队嘛，请求来了，如果前面还有请求没被执行，就排队，并且按照固定的频率去执行.
而热点参数限流则是基于令牌桶算法：热点参数的特点就是针对每个一个参数单独去统计，那么你可以看作是一个接口，比如查询商品，将来商品的参数可能就是成千上万，如果采用滑动窗口的方式，那就需要进行时间分区，并每个分区种都有一个计数器来统计，那么对内存的消耗是非常大的.? ?如果使用令牌桶，就只需要记住这个参数对应的令牌即可（上一个请求来的时间）.

文章来源:https://blog.csdn.net/CYK_byte/article/details/135759284
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若内容造成侵权/违法违规/事实不符，请联系我的编程经验分享网邮箱：chenni525@qq.com进行投诉反馈，一经查实，立即删除！