背压 - Managed Service for Apache Flink
使用丢弃接收器测试吞吐量
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异，请参阅 中国的 Amazon Web Services 服务入门 (PDF)。

Amazon Managed Service for Apache Flink 之前称为 Amazon Kinesis Data Analytics for Apache Flink。

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

背压

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

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

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

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

识别出慢速运算符后，请尝试了解为什么它很慢。可能有多种原因，有时还不清楚出了什么问题，可能需要数天的调试和分析才能解决。以下是一些显而易见且更常见的原因，其中一些原因将在下面进一步解释：

  • 操作员正在执行缓慢的 I/O，例如网络调用（考虑改用 AsyncIO）。

  • 数据存在偏差，一个操作员收到的事件比其他操作员多（通过查看 Flink 控制面板中各个子任务（即同一运算符的实例）的进出消息数量进行验证。

  • 这是一项资源密集型操作（如果没有数据偏差，可以考虑扩展 /m CPU emory 绑定工作，或者为 I/O 绑定工作增加ParallelismPerKPU规模）

  • 在操作员中进行大量日志记录（将生产应用程序的日志记录减少到最低限度，或者考虑改为将调试输出发送到数据流）。

使用丢弃接收器测试吞吐量

丢弃接收器只是忽略它在执行应用程序时收到的所有事件（没有任何接收器的应用程序无法执行）。这对于吞吐量测试、性能分析以及验证应用程序是否正常扩展非常有用。这也是一项非常实用的健全性检查，用于验证水槽是否造成了背压或应用（但是仅检查背压指标通常更容易、更简单）。

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