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

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

背压

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 控制面板中查看单个子任务（即同一个运算符的实例）的进出消息数量进行验证。

  • 这是一项资源密集型操作（如果没有数据偏差，可以考虑向外扩展 CPU/内存限制工作或增加ParallelismPerKPU用于 I/O 绑定工作）

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

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

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

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