本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 背压
<a name="troubleshooting-backpressure"></a>

Flink 使用背压来调整各个操作员的处理速度。

出于多种原因，操作员可能难以继续处理收到的消息量。该操作需要的 CPU 资源可能超过操作员的可用资源，操作员可能会等待 I/O 操作完成。如果操作员无法足够快地处理事件，则会在向慢速运算符馈送的上游操作员中产生背压。这会导致上游操作员减速，从而进一步将背压传播到源，并通过减慢速度使源系统适应应用程序的总体吞吐量。你可以在[ Apache Flink™](https://www.ververica.com/blog/how-flink-handles-backpressure) 如何处理背压中找到对背压及其工作原理的更深入的描述。

了解应用程序中哪些运算符运行缓慢，可以为你提供重要信息，帮助你了解应用程序中性能问题的根本原因。背压信息[通过 Flink 控制面板公开](https://nightlies.apache.org/flink/flink-docs-stable/docs/ops/monitoring/back_pressure/)。要识别慢速操作员，请寻找背压值较高且最接近水槽的操作员（以下示例中的操作员 B）。因此，导致缓慢的运算符就是下游运算符之一（示例中为运算符 C）。B 可以更快地处理事件，但由于无法将输出转发给实际的慢速运算符 C，因此会受到反压

```
A (backpressured 93%) -> B (backpressured 85%) -> C (backpressured 11%) -> D (backpressured 0%)
```

识别出慢速运算符后，请尝试了解为什么它很慢。可能有多种原因，有时还不清楚出了什么问题，可能需要数天的调试和分析才能解决。以下是一些显而易见且更常见的原因，其中一些原因将在下面进一步解释：
+ 操作员正在执行缓慢的 I/O，例如网络调用（考虑改用 AsyncIO）。
+ 数据存在偏差，一个操作员收到的事件比其他操作员多（通过查看 Flink 控制面板中各个子任务（即同一运算符的实例）的消息 in/out 数量进行验证。
+ 这是一项资源密集型操作（如果没有数据偏差，可以考虑向外扩展以进行 CPU/memory 绑定工作，或者为绑定工作增加`ParallelismPerKPU`规模） I/O 
+ 在操作员中进行大量日志记录（将生产应用程序的日志记录减少到最低限度，或者考虑改为将调试输出发送到数据流）。

## 使用丢弃接收器测试吞吐量
<a name="troubleshooting-testing-throughput"></a>

[丢弃接收器](https://nightlies.apache.org/flink/flink-docs-stable/api/java/org/apache/flink/streaming/api/functions/sink/DiscardingSink.html)只是忽略它在执行应用程序时收到的所有事件（没有任何接收器的应用程序无法执行）。这对于吞吐量测试、性能分析以及验证应用程序是否正常扩展非常有用。这也是一项非常实用的健全性检查，用于验证水槽是否造成了背压或应用（但是仅检查背压指标通常更容易、更简单）。

通过用丢弃的接收器替换应用程序的所有接收器，并创建一个生成类似于生产数据的数据的模拟源，您可以测量应用程序在特定并行度设置下的最大吞吐量。然后，您还可以增加并行度，以验证应用程序是否可以正常扩展，并且不会出现只有在更高的吞吐量下才会出现的瓶颈（例如，由于数据倾斜）。