译者 | 李睿
审校 | 重楼
研究表明，即使是最坚固、设计最精良的水坝也无法承受失控洪水的破坏力。同样，在分布式系统的场景中，未经限制的调用者通常会使整个系统不堪重负，并导致级联故障。如果没有适当的防护措施，重试风暴有可能使整个服务崩溃。本文将探讨服务何时应该考虑对其调用者应用背压（Backpressure），如何应用，以及调用者可以做些什么来处理背压。
背压
顾名思义，背压是分布式系统中的一种机制，指的是系统限制数据消耗或产生速度的能力，以防止自身或其下游组件过载。系统对其调用者施加背压并不总是显式的，例如以节流或减少负载的形式，但有时也是隐式的，例如通过增加服务请求的延迟而不显式地减慢自己的系统。隐式和显式背压都是为了降低调用者的速度，无论是调用者表现不佳，还是服务本身状态不佳，需要时间来恢复。
需要背压
以下举例说明系统何时需要施加背压。在这个例子中，正在构建一个包含三个主要组件的控制平台服务：一个接收客户请求的前端，一个缓冲客户请求的内部队列，以及一个从队列读取消息并写入数据库以实现持久性的消费者应用程序。
图1控制平台示例
（1）生产者与消费者不匹配
设想这样一种场景，参与者/客户以极高的频率访问前端，导致内部队列已满或写入数据库的工作线程很忙，进而造成队列满载。在这种情况下，请求不能排队，因此与其放弃客户请求，不如提前通知客户。这种不匹配可能由于各种原因而发生，例如传入流量激增或系统出现小故障，其中消费者服务曾经一度停机，但现在必须增加额外的工作时间，以有效清理并解决在停机期间所形成的工作积压问题。
（2）资源约束和级联故障
设想这样一种场景，队列接近其容量的100%，而平时在50%左右。为了匹配这种传入速率的增加，可以扩展消费者应用程序，并开始以更高的速率写入数据库。但是，数据库因无法处理这种增长（例如每秒写入次数的限制）而崩溃。这种故障将导致整个系统瘫痪，并增加平均恢复时间（MTTR）。在这种情况下，在适当的地方施加背压变得至关重要。
（3）错过服务水平协议（SLA）
考虑这样一种场景：写入数据库的数据每5分钟处理一次，另一个应用程序会监听这些数据以保持自身更新。现在，如果系统由于某种原因无法满足SLA，例如队列已满90%，可能需要10分钟才能清除所有消息，那么最好采用背压技术。可以通知客户将会错过SLA，并建议他们稍后再试，或者通过从队列中删除非紧急请求来应用背压，以满足关键事件/请求的SLA。
背压的挑战
根据上述内容，似乎应该始终应用背压，听起来确实如此，主要的挑战不是是否应该应用背压，而是如何确定应用背压的正确点，以及应用反压力的机制，以满足特定的服务/业务需求。
背压迫使在吞吐量和稳定性之间进行权衡，而负载预测的挑战使这种权衡变得更加复杂。
确定背压点
（1）查找瓶颈/薄弱环节
每个系统都存在瓶颈。有些瓶颈能够自我承受和保护，而有些则不能。设想在一个系统中，其中庞大的数据平台集群（数千台主机）依赖于一个小型控制平台集群（少于5台主机）来接收存储在数据库中的配置，如上图所示。大型集群很容易使小型集群不堪重负。在这种情况下，为了保护自己，小型集群应该具备对调用者应用背压的机制。架构中的另一个常见薄弱环节是对整个系统做出决策的集中式组件，例如反熵扫描器。如果它们失效，系统就永远无法达到稳定状态，甚至可能导致整个服务崩溃。
（2）使用系统动态：监测器/指标
另一种为系统找到回压点的常见方法是设置适当的监测器/指标。持续监控系统行为，包括队列深度、CPU/内存利用率和网络吞吐量。利用这些实时数据来识别新出现的瓶颈，并相应地调整背压点。通过指标或观察者（例如跨不同系统组件的性能金丝雀）来创建综合视图，是了解系统是否处于压力状态并应对其用户/调用者施加背压的另一种方法。这些性能金丝雀（Performance Canaries）可以针对系统的不同方面进行隔离，以找到瓶颈。此外，拥有一个内部资源使用情况的实时仪表板是另一种利用系统动态来发现关键点和采取更加积极主动措施的好方法。
（3）边界：最小惊奇原则
对客户来说，最明显的是与他们互动的服务表面区域。通常是客户用来为其请求提供服务的API。这也是客户在出现背压时最不会感到惊讶的地方，因为它清楚地表明系统处于压力之下。它能够以节流或减载的形式出现。同样的原则可以在服务本身中跨不同的子组件和接口应用，它们通过这些子组件和界面相互交互。这些表面是施加背压的最佳位置，有助于最大限度地减少混乱，使系统的行为更具可预测性。
如何在分布式系统中应用背压
在上一节中，讨论了如何找到正确的兴趣点以施加背压。一旦确定了这些点，以下是一些在实际中施加背压的方法。
构建显式流控制
这个想法是让调用者能够看到队列的大小，并根据它来控制调用速率。通过了解队列大小（或任何成为瓶颈的资源），调用者可以增加或减少调用率，以避免系统过载。这种技术在多个内部组件协同工作且尽可能不影响彼此的情况下特别有用。以下公式可以在任何时候用来计算调用者的速率。注：实际的调用速率将取决于各种其他因素，但以下这个公式应该能够提供一个很好的思路。
CallRate_new = CallRate_normal * (1 - (Q_currentSize / Q_maxSize))倒置责任
在某些系统中，可以改变调用者不直接地向服务发送请求的顺序，而是让服务请求在准备好提供服务时自行工作。这种技术使接收服务可以完全控制它可以做多少事情，并且可以根据其最新状态动态更改请求大小。可以采用令牌桶策略，其中接收服务填充令牌，并告诉调用者何时以及他们可以向服务器发送多少令牌。以下是调用者可以使用的一个示例算法：
# Service requests work if it has capacity
if Tokens_available > 0:
Work_request_size = min (Tokens_available, Work_request_size _max) # Request work, up to a maximum limit
send_request_to_caller(Work_request_size) # Caller sends work if it has enough tokens
if Tokens_available >= Work_request_size:
send_work_to_service(Work_request_size)
Tokens_available = Tokens_available – Work_request_size
# Tokens are replenished at a certain rate
Tokens_available = min (Tokens_available + Token_Refresh_Rate, Token_Bucket_size)主动调整
有时，提前知道系统很快就会不堪重负，于是采取主动措施，例如要求调用者降低调用量，然后再慢慢增加。设想这样一个场景：下游服务宕机并拒绝了所有请求。在此期间，将所有工作排在队列中，现在准备按照SLA将其清空。但是，如果以高于正常速率的速度清空队列，就有可能导致下游服务瘫痪。为了解决这个问题，可以主动限制调用者的请求量，或者与调用者沟通，要求其减少调用量，并慢慢放宽限制。
限流
限制服务能够处理的请求数量，并丢弃超出这一数量的请求。限流可以在服务层面或API层面实施。这种限流是对调用者的一种直接反馈，提示其降低调用量。可以进一步采取优先级限流或公平限流策略，以确保对客户的影响降到最低。
减载
限流是当违反某些预定义的限制时丢弃请求。如果服务面临过大压力并决定主动放弃已经承诺服务的请求，客户请求仍然可以被丢弃。这种行为通常是服务保护自己并让调用者知道它的最后手段。
结论
在分布式系统中，背压是一个重要的挑战，它会严重影响系统的性能和稳定性。了解背压的原因和后果，以及掌握有效的管理技术，对于构建健壮且高性能的分布式系统至关重要。如果实施得当，背压可以增强系统的稳定性、可靠性和可扩展性，从而提升用户体验。如果处理不当，可能会削弱客户信任，甚至导致系统不稳定。通过仔细的系统设计和监控主动应对背压是维护系统健康的关键。虽然实施背压可能涉及一些权衡，例如可能影响吞吐量，但从整体系统弹性和用户满意度来看，其带来的好处是巨大的。
原文标题：Backpressure in Distributed Systems，作者：Rajesh Pandey
