概念:是指一段时间内,定义某个客户或应用可以接受或处理多少个请求的技术。通过限流,你可以过滤掉产生流量峰值的客户和微服务,或者可以确保你的应用程序在自动扩展(Auto Scaling)前都不会出现过载的情况。
-
令牌桶、漏桶:针对单个阶段,无法分布式限流
-
QPS限流
- 不同的请求可能需要数量迥异的资源来处理
- 某种静态QPS限流不是特别准
-
给每个用户设置限制
- 全局过载发生的时候,针对某些”异常“进行控制
- 有一定程度的”超卖“配额
-
按照优先级丢弃
-
拒绝请求也需要成本
分布式限流
分布式限流:是为了控制某个 应用全局的流量,而非针对单个节点纬度
- 单个大流量的接口,使用redis容易产生热点
- pre-request模式对性能有一定的影响,高频的网络往返
思考
- 从获取单个quota升级成批量quota
quota:标识速率,获取后使用令牌桶算法来限制。
- 每次心跳后,异步批量获取quota,可以大大减少请求redis的频次,获取完后本地消费,基于令牌桶拦截
- 每次申请的配额需要手动设定静态值,略欠灵活,比如每次要20,或者50
初次使用默认是,一旦有过去历史窗口的数据,可以基于可以使窗口数据进行quota请求
思考
我们经常面临给一组用户划分稀有资源的问题,他们都享有等价的权利来获取资源,但是一些用户实际上只需要比其他用户少的资源。
那么,我们如何来分配资源呢,一种十几种广泛使用的分享技术称作”最大最小公平分享“
(Max-Min Fairness)
直观上,公平分享分配给每个用户想要的可用满足最小需求,然后将没有使用的资源均匀的分配给需要”大资源“的用户
最大最小公平分配算法的形式定义:
- 资源按照递增的顺序进行分配
- 不存用户得到的资源超过自己的需求
- 未得到满足的用户等价的分享资源
重要性
每个接口配置阈值,运营工作繁重,最简单的就是配置服务级别quota,更细颗粒度的,我们可以根据不同的重要性设置quota。
- 最重要 CRITICAL_PLUS,为最终要求预留的类型,拒绝这些请求会造成非常严重的用户可见的问题。
- 重要 CRITICAL,生产任务发出的默认请求类型。拒绝这些请求也会造成永远可见的问题。但是可能没那么严重。
- 可丢弃的 DISPOSABLE_PLUS,这些流量可以容忍某种程度的不可用性。这是批量任务发出的请求的默认值,这些请求通常可以过几分钟,几小时后重试
- 可丢弃的 DISPOSABLE 这些流量可能会经常遇到部分不可用的情况,偶尔完全不可用。
gRPC系统之间,需要自动传递重要信息。如果后端接收到请求A,在处理请求过程中发出了请求B和C给其他后端,请求 B和C会使用相同的重要性属性
- 全局配额不足是,优先拒绝低优先级的
- 全局配额,可以按照重要性分别设置
- 过载保护时,低优先级的请求先被拒绝