常见的限流算法和应用场景_常见限流算法的使用场景

1.计数器模式

假设以1分钟作为一个固定窗口，窗口流量限制为100。那么1分钟的最后1s进来100个流量，下一个窗口的第一秒进来了100个流量，其实1分钟内流量是超出系统能承受范围的。

所以，计数器模式无法应对突发的流量

2.滑动窗口

一个大窗口分成多个小窗口，每次向后滑动一个小窗口。控制了各个小窗口的流量，这种方法比上一种更加平滑。但是小窗口的划分要求很高，面对突发的流量也没有办法控制

3.漏桶

桶的容量是固定的。当有请求到来时先放到木桶中，处理请求的worker以固定的速度从木桶中取出请求进行相应。如果木桶已经满了，直接返回请求频率超限的错误码或者页面。

适用场景

木桶流入请求的速率是不固定的，但是流出的速率是恒定的。这样的话能保护系统资源不被打满，但是面对突发流量时会有大量请求失败，不适合电商抢购和微博出现热点事件等场景的限流。

漏桶算法是流量最均匀的限流实现方式，一般用于流量“整形”。例如保护数据库的限流，先把对数据库的访问加入到木桶中，worker再以db能够承受的qps从木桶中取出请求，去访问数据库。 

4.令牌桶

同时由于往木桶添加令牌的速度是恒定的，且木桶的容量有上限，所以单位时间内处理的请求书也能够得到控制，起到限流的目的。假设加入令牌的速度为 1token/10ms，桶的容量为500，在请求比较的少的时候（小于每10毫秒1个请求）时，木桶可以先"攒"一些令牌（最多500个）。当有突发流量时，一下把木桶内的令牌取空，也就是有500个在并发执行的业务逻辑，之后要等每10ms补充一个新的令牌才能接收一个新的请求。（超大并发时，有一定的缓存时间，会拒绝一部分请求）

参数设置
木桶的容量  - 考虑业务逻辑的资源消耗和机器能承载并发处理多少业务逻辑。

生成令牌的速度 - 太慢的话起不到“攒”令牌应对突发流量的效果。

适用场景
适合电商抢购或者微博出现热点事件这种场景，因为在限流的同时可以应对一定的突发流量。

————————————————
版权声明：本文为CSDN博主「kevin_tech」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/kevin_tech/article/details/111465877