可用性设计之限流

概念：是指一段时间内，定义某个客户或应用可以接受或处理多少个请求的技术。通过限流，你可以过滤掉产生流量峰值的客户和微服务，或者可以确保你的应用程序在自动扩展（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会使用相同的重要性属性

• 全局配额不足是，优先拒绝低优先级的
• 全局配额，可以按照重要性分别设置
• 过载保护时，低优先级的请求先被拒绝