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

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

背压

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

操作员可能难以继续处理收到的消息量，原因有很多。该操作可能需要的 CPU 资源可能超过操作员可用的 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 仪表板中各个子任务（即同一个操作员的实例）的传入/传出消息数量进行验证。

  • 这是一项资源密集型操作（如果不存在数据偏差，可以考虑向外扩展到 CPU/内存密集型工作，或者增加对 I/O 限制的工作ParallelismPerKPU进行扩展）

  • 操作员大量登录（将生产应用程序的日志记录降至最低，或者考虑改为将调试输出发送到数据流）。

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

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

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