分布式限流介绍
1、分布式限流的集中纬度
时间 限流基于某段时间范围或者某个时间点，也就是我们常说的“时间窗口”，比如对每分钟、每秒钟的时间窗口做限定
资源
资源 基于可用资源的限制，不如设定最大访问次数，或最高可用连接数
上面连个纬度结合起来看，限流就是在某个时间窗口对资源访问的限制，比如设定每秒最多100个访问请求。但在真正的场景里，不止设置一种限流规则，而是会设置多个限流规则共同作用，主要有的几种限流规则：
QPS 和连接数量控制
针对上图中的连接数和 QPS 限流来说，我们可以设定 IP 纬度的限流，也可以设置基于单个服务器的限流。在真实环境中通常会设置多个纬度的限流规则，比如设定同一个 IP 每秒访问频率小于10，连接数小于5，再设定每台机器QPS最高1000，连接数最大保持200。更进一步，我们可以把某个服务器组或整个机房的服务器当做一个整体，设置更high-hevel 的限流规则，这些所有限流规则都会共同作用于流量控制。
传输速率
对于“传输速率”大家都不会陌生，比如资源的下载速度。有的网站在这个方面的限流逻辑做的更细致，比如普通用户下载速度 100k/s，会员用户下载速度 10m/s，这背后就是基于用户组或者用户标签的限流逻辑。
黑白名单
黑白名单是各个大型企业应用里很常见的限流和放行手段，而且黑白名单往往是动态变化的。举个例子：如果某个 IP 在一段时间的访问次数过于频繁，被系统识别为机器人用户或流量攻击，那么这个 IP 就会被加入到黑名单，从而限制其对系统资源的访问，这就是我们俗称的“封IP”。
我们平时见到的爬虫，一般都必须实现更换IP的功能，以防止加入黑名单。
白名单就更好理解，相当于御赐金牌在身，可以自由穿梭于各种限流规则里，畅行无阻。
分布式环境
所谓的分布式限流，其实道理很简单。分布式区别于单机限流的场景，它把整个分布式环境中所有服务器当做一个整体来考量。比如说针对IP限流，我们限制了1个IP每秒最多10个访问，不管来自这个IP地址的请求落在了哪台机器上，只要是访问了集群中的服务节点，那么都会受到限制规则的制约。
从上面的例子不难看出，我们必须将限流信息保存在一个“中心化”的组件上，这样它就可以获取到集群中所有机器的访问状态，目前有两个比较主流的限流方案：
网关层限流 将限流规则应用在所有流量的入口处
中间件限流 将限流信息存储在分布式环境中某个中间件里（比如redis），每个组件都可以从这里获取到当前时间的流量统计，从而决定是否放行还是拒绝。
2、分布式限流方案
1、网关层限流
在整个分布式系统中，如果有这么一个“一夫当关，万夫莫开”的角色，非网关层属。服务网关作为整个分布式链路中的第一道关卡，承接了所有的访问请求。
网关层限流的架构考量
漏斗是个好东西，不仅可以用来打香油，还可以应用在很多系统设计的领域，我们将系统流量的分布式层次抽象成一个简单的漏斗模型来看
从上到下的路径依次是：
1、用户流量从网关层转发到后台服务
2、后台服务承接流量，调用缓存获取数据
3、缓存中无数据，则访问数据库
为什么说它是一个漏斗模型，因为流量自上而下是逐层递减的，在网关层聚集了最多最密集的用户访问请求，其次是后台服务。然后经过后台服务的验证逻辑之后，刷掉了一部分错误请求，剩下的请求落在缓存上，如果换纯种没有数据才会请求漏斗最下方的数据库，因此数据库层面请求数量最小。
如果在上面这个漏斗模型中做流量限制，最合适的就是网关层，因为它是整个访问链路的源头，是所有流量途径的第一站。目前主流的网关层是以软件为代表的 Nginx，还有 spring Cloud 中的 Gateway 和 Zuul 这类网关层组件。
2、中间件限流
开发团队对于网关层限流对他们来说有点不受控制，毕竟不像程序代码那么简单，搞不好还要求运维团队去操作。
对于分布式环境来说，无非是需要一个类似中兴节点的地方存储限流数据。打个比方，如果我希望控制接口的访问速率为每秒100个请求那么我就需要将当前1s内已经接收到的请求数量保存在某个地方，并且可以让集群环境中所有接待您都能访问。那我们可以用什么技术来存储这个临时数据呢？那必须 Reddis 啊。
限流组件
Sentinel(阿里出品的开源组件)，并且包含在了spring Cloud Alibaba组件库中。
在真实的项目中，不会只使用一种限流手段，往往是几种方式互相搭配使用，让限流策略有一种层次感，达到资源的最大使用率。在这个过程中，限流策略的设计也可以设计也可以参考前面的漏斗模型，上宽下紧，漏斗不同部位的限流方案设计要尽量关注当前组件的高可用。
