1、限流的策略

2、限流的算法：计数器、队列、漏斗和令牌桶。

3、如何基于响应时间来限流。

4、限流设计的要点

例：数据库访问连接池，线程池， nginx 下的用于限制瞬时并发连接数的 limit_conn 模块，限制每秒平均速率 limit_req 模块，限制 MQ 的生产速，等等。

一、限流的策略

拒绝服务。拒掉请求最多客户端，把不正常或是恶意的高并发访问抵挡掉。

服务降级。(1)不重要的服务停掉， CPU、内存或数据让给重要功能；(2)不返回全量数据，返回部分

全量数据需要做 SQL Join 操作，部分则不需要，所以可以让 SQL 执行更快，或直接返回预设的缓存，牺牲一致性，获大吞吐。

特权请求。保大客户的

延时处理。队列缓冲请求，队列满了拒绝，如果这个队列中的任务超时了，也要返回系统繁忙的错误了。应对短暂峰刺请求。

弹性伸缩。监控系统，感知忙 TOP 5服务

然后去伸缩它们，还需要一个自动化的发布、部署和服务注册的运维系统，而且还要快，越快越好。否则，系统会被压死掉了。db压力大，弹性伸没什么用，应限流

二、限流的实现方式

1、计数器方式

一个请求来加一，请求处理完减一Counter 大于限流阈值，开始拒绝请求以保护系统的负载了。

2、队列算法

请求速度波动的，处理速度均速。像 FIFO，先高优先级，再处理低优先级

低队列被饿死，有带权重的队列。下图：三个队列的权重分布是 3:2:1，权重 3 的这个队列上处理 3 个请求后，再去权重 2 的队列上处理 2 个请求，最后去 1 的队列上处理 1 个请求，返复。

队列满，触发限流：用队列长度来控制流量，配置上难操作。过长导致没满就挂掉了。不能做 push ，pull 方式会好一些

3、漏斗算法 Leaky Bucket

像漏斗一样，漏斗中水太多，溢出

实现：队列请求 + 限流器，让 Processor 匀速处理

如 TCP。请求过多， sync backlog 队列缓冲请求，或TCP 滑动窗口

4、令牌桶算法 Token Bucket

有中间人。在桶内按照一定速率放入token，拿到 token，才能处理

漏斗算法中，处理请求是以一个常量和恒定的速度处理的，而令牌桶算法则是在流量小的时候“攒钱”，流量大的时候，快速处理。

如Processor 像 Nginx 没什么逻辑，速度快，没瓶颈，而把请求转给后端，这两个算法就不一样了：

    漏斗算法：稳定的速度转发

    令牌桶：流量大时，一次发出。还可做第三方服务，对全局进行流控

三、基于响应时间动态限流

1、服务会依赖于数据库。数据不断片花

2、不同 API 不同性能。

3、自动化伸缩情况下，不同大小集群的性能也不一样，动态地调整太难

因为123 很难设定限流值，感知系统压力，来自动化地限流

典范： TCP 协议拥塞控制算法。TCP 使用 RTT - Round Trip Time 来探测网络的延时和性能，设定相应“滑动窗口”的大小，发送速率和网络性能相匹配。

记录每次调用后端请求的响应时间，在时间区间内（如过去 10 秒）请求计算响应时间 P90 或 P99 值，过去 10 秒请求响应时间排序，看 90% 或 99% 位置多少（超过设定阈值，自动限流）

设计中要点：

计算的一定时间内的 P90 或 P99。大量请求下，非常地耗内存和 CPU，因为要对大量数据排序。

解决方案有两种，一种是不记录所有的请求，采样就好了，另一种是使用一个叫蓄水池的近似算法。关于这个算法这里我不就多说了，《编程珠玑》里讲过这个算法，你也可以自行 Google，英文叫Reservoir Sampling。

这种动态流控需要像 TCP 那样，你需要记录一个当前的 QPS. 如果发现后端的 P90/P99 响应太慢，那么就可以把这个 QPS 减半，然后像 TCP 一样走慢启动的方式，直接到又开始变慢，然后减去 1/4 的 QPS，再慢启动，然后再减去 1/8 的 QPS……

这个过程有点像个阻尼运行的过程，然后整个限流的流量会在一个值上下做小幅振动。这么做的目的是，后端扩容伸缩后性能变好，自动适应后端的最大性能。

四、限流的设计要点

限流目的：

1、为了向用户承诺 SLA。保证某个速度下的响应时间以及可用性。

2、阻止多租户的情况下，某一用户把资源耗尽，而让所有的用户都无法访问的问题。

3、应对突发的流量。

4、节约成本。不为不常见的尖峰扩容到最大的尺寸。有限的资源下能够承受比较高的流量。

设计上的考量：

1、早期考虑。当架构形成后，限流不是很容易加入。

2、限流模块必需是非常好的性能，而且对流量的变化也是非常灵敏的，否则太过迟钝的限流，系统早因为过载而挂掉了。

3、手动的开关，应急。

4、监控事件通知。运维人员可以及时跟进。还可以自动化触发扩容或降级。

5、返回限流错误码。和其它错误区分开来。客户端看到限流，可以调整发送速度，或走重试机制。

6、让后端的服务感知到。比如 HTTP Header 中，放入一个限流的级别，告诉后端服务目前正在限流中。这样，后端服务可以根据标识决定是否做降级。

也欢迎你分享一下你实现过怎样的限流机制？