画布 1
SRE-谷歌运维揭秘
  21 章 应对过载
    系统的某个部位总是会过载
    优雅地避免过载是负载均衡的一个重要目标
      可能的时候重定向请求
      在必要时返回降级回复
      在最差的情况下，能够妥善地处理资源受限导致的错误
    容量规划
      错误方法
        基于 qps
        基于某些静态指标
      正确方法
        直接以可用资源来建模
          通常一个请求的成本是它消耗的 cpu 时间
            在有垃圾回收机制的编程环境里，内存的压力通常自然而然地变成 cpu 的压力
    给每个用户设置限制
      如何处理全局过载（global overload）
        通用后端服务就像空气和水一样，大家都误以为可以取之不尽。因为缺乏规划，所以出现全局过载的情况非常频繁。
        要让后端服务团队和客户团队协商，建立配额机制
          要识别用户
          识别用户消耗的资源
          能够把全局的配额摊到局部
    客户端侧的节流限制
      有些请求在服务端拒绝消耗的资源比客户端拒绝消耗的大，这时候就应该实现客户端节流
        客户端如何检测到“配额不足”的错误？
          客户端请求拒绝概率=max(0,(requests - K * accepts)/ requests +)
            在没有开始节流以前，requests == accepts
            降低 k 值会让节流算法更加激进
            k = 1 时，且 accepts == requests 时，拒绝概率为 0
            通常这个值为 2（略为激进，这可以让后端状态更快地传递到前端）
          在客户端内部，请求按照概率被拒绝
          尽快让客户端感知到服务端失败和恢复，是很重要的
    重要性 criticality
      CRITICAL_PLUS
      CRITICAL
      SHEDDABLE_PLUS
      SHEDDABLE
      概要
        根据优先级设计阈值
        在某些过载发生时，低优先级的请求先被拒绝
        跨服务兼容需要标准化和在 RPC 系统中自动传递
        重要性最好在离客户最近的地方设置（比如浏览器）
    资源利用率信号
      执行器负载均值 executor load average
        统计活跃线程数（大致等于 runnable 线程）
      使用指数衰变算法 exponential decay 来平滑这个数字
    处理过载错误
      如果服务大规模失败，则所有请求都不应该重试，反之则应该允许重试
        所有的不允许重试应该反馈到最上游
      不必严格区分新请求和老请求
      立即失败 + 立即重试可以形成一种天然的负载均衡机制
    决定何时重试
      请求的重试次数要受限，通常为 3 次。如果一个请求（经过负载均衡）连续三次选中了过载的任务，整个数据中心可能都处于过载状态。
      客户端的请求重试次数占请求总数比较低的时候，才会触发重试，这样可以感知全局过载。
      如果后端有基于统计次数的元数据的统计模型，它可以实现一些启发式的推测，认为整个系统都在过载中，于是它会发出“过载、无需重试”的响应，而不是简单的“过载”。
      深层次的系统依赖决定了我们应该限定我们的重试的范围，防止 retry-blast
    连接造成的负载
      问题：连接消耗资源，连接快速变动，连接健康检查也会消耗意想不到的资源
      解法
        整个系统的 gateway、网关、保险丝，到底隐藏在架构的什么地方
        使用负载均衡算法处理突发大批量任务
        使用一个专属的代理，让这个代理起到保险丝的作用
  概要
    1. 建立流量模型，确立基本认知
    2. 建立配额机制
    3. 建立统计模型
    4. 提供重试机制
    5. 基于 2、3、4进行限流