Netflix的文章《Keeping Netflix Reliable Using Prioritized Load Shedding》探讨了Netflix如何通过引入基于优先级的减载法（Prioritized Load Shedding）来改进系统可用性，确保在系统高负载或故障时仍能保障基础功能可用。

在接入层或者后端服务中，通常会有类似Hystrix的限流器来保障服务的可用性。但是限流器通常没有区分流量的优先级，而是让每个请求都按照统一的处理策略（包括流量控制、熔断降级以及过载保护等，参考sentinel-go源码分析）

Netflix引入了基于优先级减载法，该方法的核心思想是根据请求的优先级来逐步限制流量，确保关键请求得到优先处理，而较低优先级的请求在必要时被丢弃。

当前（本文发表时间2020年）的限流措施集中在Netflix的接入层网关（Zuul）上，Zuul 可以在请求生命周期的两个时刻应用负载削减。

从三个维度对请求流量进行分类：吞吐量、功能性和关键性。根据这些特征，流量被分为以下几类：：

Netflix使用API网关服务（Zuul）来根据请求的属性将请求分类为 NON_CRITICAL、DEGRADED_EXPERIENCE 和 CRITICAL 存储桶（即上面的三个分类），并根据每个请求的各自特征计算 1 到 100 之间的优先级分数（priority score）。这些属性包括吞吐量、功能性和重要性。

大多数情况下，请求工作流会正常进行，无需考虑请求优先级。但是故障发生时（后端出现问题或 网关Zuul 本身出现问题），优先级较高的请求会得到优先处理，而优先级较低的请求则可能不会被处理。该实现类似于具有动态优先级阈值的优先级队列。这允许 Zuul 丢弃优先级分数低于当前优先级阈值的请求。

负载过高时，我们会从最低优先级开始逐步减少流量。使用立方函数（Cubic function）来管理节流级别。确保在极端情况下也能保持服务的部分可用性。

上图是Cubic function应用的示例。随着过载百分比的增加（即节流阈值和最大容量之间的范围），优先级阈值会非常缓慢地落后于它：在 35% 时，它仍然在 95% 左右。如果系统继续降级，我们会在超过 80% 时达到优先级 50，然后在超过 95% 时最终达到优先级 10，依此类推。

当 Zuul 决定丢弃流量时，它会向终端设备发送信号，让终端知道我们需要它们退出重试。它通过指示它们可以执行多少次重试以及它们可以在什么样的时间窗口中执行重试来实现这一点。例如：

{ “maxRetries” : <max-retries>, “retryAfterSeconds”: <seconds> }

使用这种背压（Back Pressure）机制，我们可以比过去更快地阻止重试风暴。我们根据请求的优先级自动调整这两个拨盘。优先级较高的请求将比优先级较低的请求更积极地重试，从而提高流式传输的可用性。

如何确定某个请求的优先级分类，以及如何保障策略的长期有效。

为了验证我们的请求分类假设，即特定请求是否属于 NON_CRITICAL、DEGRADED 或 CRITICAL 分类，我们需要一种方法来测试该请求失败时的用户体验。为了实现这一点，我们利用了内部故障注入工具 ( FIT )，并在 Zuul 中创建了一个故障注入点，使我们能够根据提供的优先级删除任何请求。这使我们能够通过阻止特定设备或成员的优先级范围来手动模拟负载删除体验，让我们了解哪些请求可以安全地删除而不会影响用户。

Netflix 拥有各种各样的客户端设备、客户端版本以及与系统交互的方式。为了确保在任何这些情况下限制非关键请求时不会给会员带来痛苦，我们利用了我们的基础设施实验平台ChAP。

该平台允许我们进行 A/B 实验，将少数生产用户分配到对照组或实验组，持续 45 分钟，同时限制实验组的一系列优先级。这让我们能够捕获各种实时用例并衡量其对播放体验的影响。ChAP 分析成员的每台设备 KPI，以确定对照组和实验组之间是否存在偏差。