滑动窗口其实也是一种计算器算法，它有一个显著特点，当时间窗口的跨度越长时，限流效果就越平滑。打个比方，如果当前时间窗口只有两秒，而访问请求全部集中在第一秒的时候，当时间向后滑动一秒后，当前窗口的计数量将发生较大的变化，拉长时间窗口可以降低这种情况的发生概率

常用的限流方案

合法性验证限流

比如验证码、IP 黑名单等，这些手段可以有效的防止恶意攻击和爬虫采集；

Guawa限流

在限流领域中，Guava在其多线程模块下提供了以RateLimiter为首的几个限流支持类，但是作用范围仅限于“当前”这台服务器，也就是说Guawa的限流是单机的限流，跨了机器或者jvm进程就无能为力了 比如说，目前我有2台服务器[Server 1，Server 2]，这两台服务器都部署了一个登陆服务，假如我希望对这两台机器的流量进行控制，比如将两台机器的访问量总和控制在每秒20以内，如果用Guava来做，只能独立控制每台机器的访问量<=10。

尽管Guava不是面对分布式系统的解决方案，但是其作为一个简单轻量级的客户端限流组件，非常适合来讲解限流算法

网关层限流

服务网关，作为整个分布式链路中的第一道关卡，承接了所有用户来访请求，因此在网关层面进行限流是一个很好的切入点 上到下的路径依次是：

1. 用户流量从网关层转发到后台服务
2. 后台服务承接流量，调用缓存获取数据
3. 缓存中无数据，则访问数据库

流量自上而下是逐层递减的，在网关层聚集了最多最密集的用户访问请求，其次是后台服务。

然后经过后台服务的验证逻辑之后，刷掉了一部分错误请求，剩下的请求落在缓存上，如果缓存中没有数据才会请求漏斗最下方的数据库，因此数据库层面请求数量最小（相比较其他组件来说数据库往往是并发量能力最差的一环，阿里系的MySQL即便经过了大量改造，单机并发量也无法和Redis、Kafka之类的组件相比）

目前主流的网关层有以软件为代表的Nginx，还有Spring Cloud中的Gateway和Zuul这类网关层组件

Nginx限流

在系统架构中，Nginx的代理与路由转发是其作为网关层的一个很重要的功能，由于Nginx天生的轻量级和优秀的设计，让它成为众多公司的首选，Nginx从网关这一层面考虑，可以作为最前置的网关，抵挡大部分的网络流量，因此使用Nginx进行限流也是一个很好的选择，在Nginx中，也提供了常用的基于限流相关的策略配置.

Nginx 提供了两种限流方法：一种是控制速率，另一种是控制并发连接数。

控制速率

我们需要使用 limit_req_zone 用来限制单位时间内的请求数，即速率限制，

因为Nginx的限流统计是基于毫秒的，我们设置的速度是 2r/s，转换一下就是500毫秒内单个IP只允许通过1个请求，从501ms开始才允许通过第2个请求。

• 控制速率优化版

上面的速率控制虽然很精准但是在生产环境未免太苛刻了，实际情况下我们应该控制一个IP单位总时间内的总访问次数，而不是像上面那样精确到毫秒，我们可以使用 burst 关键字开启此设置

burst=4意思是每个IP最多允许4个突发请求

控制并发数

利用 limit_conn_zone 和 limit_conn 两个指令即可控制并发数

其中 limit_conn perip 10 表示限制单个 IP 同时最多能持有 10 个连接；limit_conn perserver 100 表示 server 同时能处理并发连接的总数为 100 个。

注意：只有当 request header 被后端处理后，这个连接才进行计数。

中间件限流

对于分布式环境来说，无非是需要一个类似中心节点的地方存储限流数据。打个比方，如果我希望控制接口的访问速率为每秒100个请求，那么我就需要将当前1s内已经接收到的请求的数量保存在某个地方，并且可以让集群环境中所有节点都能访问。那我们可以用什么技术来存储这个临时数据呢？

那么想必大家都能想到，必然是redis了，利用Redis过期时间特性，我们可以轻松设置限流的时间跨度（比如每秒10个请求，或者每10秒10个请求）。同时Redis还有一个特殊技能–脚本编程，我们可以将限流逻辑编写成一段脚本植入到Redis中，这样就将限流的重任从服务层完全剥离出来，同时Redis强大的并发量特性以及高可用集群架构也可以很好的支持庞大集群的限流访问。【reids + lua】

限流组件

除了上面介绍的几种方式以外，目前也有一些开源组件提供了类似的功能，比如Sentinel就是一个不错的选择。Sentinel是阿里出品的开源组件，并且包含在了Spring Cloud Alibaba组件库中，Sentinel提供了相当丰富的用于限流的API以及可视化管控台，可以很方便的帮助我们对限流进行治理

从架构维度考虑限流设计

在真实的项目里，不会只使用一种限流手段，往往是几种方式互相搭配使用，让限流策略有一种层次感，达到资源的最大使用率。在这个过程中，限流策略的设计也可以参考前面提到的漏斗模型，上宽下紧，漏斗不同部位的限流方案设计要尽量关注当前组件的高可用。

以我参与的实际项目为例，比如说我们研发了一个商品详情页的接口，通过手机淘宝导流，app端的访问请求首先会经过阿里的mtop网关，在网关层我们的限流会做的比较宽松，等到请求通过网关抵达后台的商品详情页服务之后，再利用一系列的中间件+限流组件，对服务进行更加细致的限流控制

具体的实现限流的手段

1）Tomcat 使用 maxThreads来实现限流。

2）Nginx的limit_req_zone和 burst来实现速率限流。

3）Nginx的limit_conn_zone和 limit_conn两个指令控制并发连接的总数。

4）时间窗口算法借助 Redis的有序集合可以实现。

5）漏桶算法可以使用Redis-Cell来实现。

6）令牌算法可以解决Google的guava包来实现。

需要注意的是借助Redis实现的限流方案可用于分布式系统，而guava实现的限流只能应用于单机环境。如果你觉得服务器端限流麻烦，可以在不改任何代码的情况下直接使用容器限流（Nginx或Tomcat），但前提是能满足项目中的业务需求。

Tomcat限流

Tomcat 8.5 版本的最大线程数在 conf/server.xml 配置中，maxThreads 就是 Tomcat 的最大线程数，当请求的并发大于此值（maxThreads）时，请求就会排队执行，这样就完成了限流的目的。

注意：

maxThreads 的值可以适当的调大一些，Tomcat默认为 150（Tomcat 版本 8.5），但这个值也不是越大越好，要看具体的服务器配置，需要注意的是每开启一个线程需要耗用 1MB 的 JVM 内存空间用于作为线程栈之用，并且线程越多 GC 的负担也越重。