大家好，我是 Snow Hide，作为《左耳听风》这个专栏的学员之一，这是我打卡的第 18 天，也是我第 18 次进行打卡这种操作。

今天我温习了该专栏里一篇叫《弹力设计篇之“限流设计”》的文章。

关键词总结：限流的策略（拒绝服务、服务降级、特权请求、延迟处理、弹性伸缩）、限流的实现方式（计数器方式、队列算法、漏斗算法 / Leaky Bucket、令牌桶算法 / Token Bucket、基于响应时间的动态限流）、限流的设计要点。

 

所学总结：

 

限流的策略

限流，是对并发访问进行限速。

拒绝服务

一般的做法，是当流量暴增的时候，将同一时间内发起请求数最多的客户端请求全部丢弃。这种方法可以抵挡住恶意发起的高并发请求。

服务降级

降级，通常是提高资源利用率的一种做法。
降级的方式有：

• 保住关键服务：放弃非关键服务，将硬件/软件资源让给系统的关键服务；
• 提高整体性能：抛弃非关键或不要求实时显示的数据，只返回关键的数据或缓存里的数据。

特权请求

将流量让给大客户，对小客户做限流处理（就像那个坑爹地某度网盘）。

延迟处理

在请求量达到峰值时，只能将大量的请求积压在消息队列里，慢慢处理。

弹性伸缩

当非数据层相关的服务处理不过来的时候，监控系统需要能够感知到，并对其做水平扩充操作，当服务不那么繁忙时，再将扩充的资源回收。
 

限流的实现方式

计数器方式

我们可以定义一个计数器，作用是统计未处理请求的数量，如果未处理请求的数量大于等于配置的阈值（计数器可以存储的未处理请求数量上限）时，系统将自动丢弃新的请求。

队列算法

先进，但是未必先出。消息队列按照请求的优先级，从高往低依次处理每一个请求。如果队列被挤满，则丢弃新的请求。

漏斗算法 / Leaky Bucket

匀速处理没有被丢弃的请求，队列被挤满后，丢弃新的请求。

令牌桶算法 / Token Bucket

按照设定的速度收录请求，正常情况下按照设定的速度处理请求，但并非一直按匀速来处理请求，在请求激增时，处理的速度也会相应的有所增长。

基于响应时间的动态限流

很难设定限流值的原因

• 数据方面：请求数据所消耗的时间和资源，以及期间各种操作的处理速度一般由语句、数据量以及配置来决定；
• API 方面：请求 API 所消耗的时间和资源，以及期间各种操作的处理速度一般由服务复杂度决定；
• 平台方面：请求服务所消耗的时间的资源，以及期间各种操作的处理速度一般由其所处的平台决定。

拥塞控制算法设计要点

• 两种方案：
  • 不记录所有请求，只采样；
  • 蓄水池近似算法。
• 记录当前 QPS，若后端 P90/P99 响应太慢，则将 QPS 减半并以慢启动方式进行处理，依此类推，每次减半；
• 参考 TCP 的算法，实现过程比较复杂。
   

限流的设计要点

限流的目的

• 在指定的速度下要保持一个范围内的响应时间以及可用性；
• 确保多租户间的情况下，整体系统的资源不会被某个租户所用超；
• 流量激增时的措施，是封闭现有管道，还是临时增添几条管道；
• 在尽可能节省成本的情况下将资源的利用率最大化。

需要考虑的地方

• 兵马未动，粮草先行。在一开始就做好限流的准备；
• 限流的实现不可以产生阻塞；
• 允许人工干预限流操作；
• 限流事件需要被监控；
• 定制限流产生的错误码；
• 让后端感知限流的等级。
   

末了

重新总结了一下文中提到的内容：限流的目的、限流的策略、限流的算法、计数器、队列、漏斗、令牌桶、基于响应时间限流、限流的设计要点。