前言

​ 当资源成为瓶颈时，服务框架需要对消费者做限流，启动流控保护机制。流量控制有多种策略，比较常用的有：针对访问速率的静态流控、针对资源占用的动态流控、针对消费者并发连接数的连接控制和针对并行访问数的并发控制。

常见限流方式

静态流控

​ 主要针对客户端访问速率进行控制，它通常根据服务质量等级协定（SLA）中约定的QPS做全局流量控制，例如订单服务的静态流控阈值为100 QPS，则无论集群有多少个订单服务实例，它们总的处理速率之和不能超过100 QPS。

动态流控

​ 它的最终目标是为了保命，并不是对流量或者访问速度做精确控制。当系统负载压力非常大时，系统进入过负载状态，可能是CPU、内存资源已经过载，也可能是应用进程内部的资源几乎耗尽，如果继续全量处理业务，可能会导致长时间的Full GC、消息严重积压或者应用进程宕机，最终将压力转移到集群其它节点，引起级联故障。触发动态流控的因子是资源，资源又分为系统资源和应用资源两大类，根据不同的资源负载情况，动态流控又分为多个级别，每个级别流控系数都不同，也就是被拒绝掉的消息比例不同。每个级别都有相应的流控阈值，这个阈值通常支持在线动态调整。

并发控制

​ 针对线程的并发执行数进行控制，它的本质是限制对某个服务或者服务的方法过度消费，耗用过多的资源而影响其它服务的正常运行。并发控制有两种形式：针对服务提供者的全局控制和针对服务消费者的局部控制。

连接控制

​ 通常分布式服务框架服务提供者和消费者之间采用长连接私有协议，为了防止因为消费者连接数过多导致服务端负载压力过大，系统需要支持针对连接数进行流控。

分布式限流

​ 以上限流方式只能针对单机进行限流，无法根据实际需要进行流量限制，接下来介绍一下分布式限流方案。

计数服务

1. 开发一个技术服务模块
2. 配置模块进行限流额度配置
3. 每次请求上报到 redis
4. 进行请求计数统计
5. 限流模块进行超额判断

​ 问题：

1. Redis 单点问题
2. 每次请求都要上报，多一次缓存的网络请求，对性能有影响
3. 固定配额，不够灵活

计数服务2.0

​

​ 图源：极客时间- go 编程训练营

1. 管理后台配置额度
2. 服务端分配额度
3. API网关请求额度
4. API 网关基于令牌桶算法本地进行限流
5. 本地进程异步上报令牌，服务端根据管理后台配置和算法重新分配限额

分布式限流

​ 最大最小分配算法

1. 初始分配默认配额
2. 一旦有历史窗口的值可以基于历史窗口的值统计进行配额请求
3. 如上图所示
   1. 假设起初总配额是10
   2. A请求2、B请求2.6、C请求4、D请求5配额
   3. 先进行平均分配，10/4 每人分配 2.5 个配额
   4. A只需要2个，所以分配2，多出0.5进一步分配
   5. 0.5/3 + 2.5, B、C、D 各分配2.666
   6. B 只申请了 2.6 个配额，所以多出 0.06 个配额
   7. 0.06/2 + 2.666 , C、D 分配 2.7 个配额
   8. 分配结束，每个服务都尽量做到了公平的资源最大分配

​ 加权最大最小分配算法

1. 有四个用户，A、B、C、D 分别申请资源 2、4、4、10
2. 权重分别为 4、2.5、1、0.5
3. 资源总量16
4. 对权重进行标准化分别乘10，再化简，得到：8、5、2、1
5. A 分得配额8、B 5、C 2、D 1
6. 由于A 只需要资源2、B只需要资源4，因此A+B多出资源 7
7. 多出的资源再分配给C、D， C=2+7*(2/3)、D=1+7*(1/3)
8. 一次C获得的资源为 6.666, D获得的资源为3.333
9. 将C多出的 6.666-4=2.222 再次分配给D
10. 所以D获得的资源为 2.222+3.333=5.555

Reference

1. 微服务治理的技术演进和架构实践
2. max-min fairness 最大最小公平算法