快速学习-sentinel系统负载保护

8、系统负载保护

8.1 背景

在开始之前，先回顾一下Sentinel 做系统负载的保护的目的：

• 保证系统不被拖垮
• 在系统稳定的前提下，保持系统的吞吐量
  长期以来，系统负载保护的思路是根据硬指标，即系统的负载(load1) 来做系统过载保护。当系统负载高于某个阈值，就禁止或者减少流量的进入；当load 开始好转，则恢复流量的进入。这个思路给我们带来了不可避免的两个问题：
• load 是一个“果”，如果根据load 的情况来调节流量的通过率，那么就始终有延迟性。也就意味着通过率的任何调整，都会过一段时间才能看到效果。当前通过率是使load 恶化的一个动作，那么也至少要过1 秒之后才能观测到；同理，如果当前通过率调整是让load 好转的一个动作，也需要1 秒之后才能继续调整，这样就浪费了系统的处理能力。所以我们看到的曲线，总是会有抖动。
• 恢复慢。想象一下这样的一个场景（真实），出现了这样一个问题，下游应用不可靠，导致应用RT 很高，从而load 到了一个很高的点。过了一段时间之后下游应用恢复了，应用RT 也相应减少。这个时候，其实应该大幅度增大流量的通过率；但是由于这个时候load 仍然很高，通过率的恢复仍然不高。

TCP BBR 的思想给了我们一个很大的启发。我们应该根据系统能够处理的请求，和允许进来的请求，来做平衡，而不是根据一个间接的指标（系统load）来做限流。最终我们追求的目标是在系统不被拖垮的情况下，提高系统的吞吐率，而不是load 一定要到低于某个阈值。