Flink背压的理解总结

72 阅读 0 评论 48 点赞

我是靠谱客的博主紧张枫叶，最近开发中收集的这篇文章主要介绍Flink背压的理解总结，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

Flink 运行时的构建块是操作符和流。每个操作符都在使用中间流，通过对它们进行转换，产生新的流。描述网络机制的最佳类比是 Flink 使用具有有限容量的有效分布式阻塞队列。与 Java 连接线程的常规阻塞队列一样，一旦队列的缓冲区耗尽（有界容量），处理速度较慢的接收器就会降低发送器发送数据的速度。

可以看一下这个外国博主的描述被压机制图片，

记录“A”进入Flink，被Task 1处理。
记录被序列化到缓冲区中，
这个缓冲区被传送到任务 2，然后从缓冲区读回记录。

为了使记录通过 Flink 进行处理，需要有可用的缓冲区。

在 Flink 中，这些分布式队列是逻辑流，有界容量是通过每个生产和消费流的托管缓冲池实现的。缓冲池是一组缓冲区，在它们被消费后会被重新回收。

总体思路很简单：从池中取出一个缓冲区，将数据放入缓冲区中，在数据被消费后，将缓冲区放回池中，由此实现缓冲区的利用高效性和防止因为不断创建缓冲池导致的时间消耗。

这些池的大小在运行时动态变化。

网络堆栈中的内存缓冲区量（= 队列容量）定义了系统在不同发送器/接收器速度下可以执行的缓冲量。Flink 保证总是有足够的缓冲区来进行*一些进程*，但是这个进程的速度是由用户程序和可用内存量决定的。

更多的内存意味着系统可以简单地缓冲掉某些瞬态背压（短周期、短 GC）。更少的内存意味着对背压的更直接的反应。

以上面的简单示例为例：任务 1 在输出端有一个与之关联的缓冲池，在其输入端有任务 2。如果有一个缓冲区可用于序列化“A”，我们将其序列化并分派缓冲区。

我们必须在这里看两种情况：

本地交换：如果任务 1 和任务 2 都运行在同一个工作节点（TaskManager）上，则缓冲区可以直接交给下一个任务。一旦任务 2 消费了它，它就会被回收。如果任务 2 比 1 慢，则缓冲区的回收率将低于任务 1 能够填充的速度，从而导致任务 1 的速度变慢。
远程交换：如果任务 1 和任务 2 在不同的工作节点上运行，缓冲区可以在线路（TCP 通道）上一经回收。在接收端，数据从连线复制到输入缓冲池的缓冲区中。如果没有可用的缓冲区，则从 TCP 连接中读取数据将被中断。输出端永远不会通过简单的水印机制将太多数据放在线路上。如果有足够的数据在传输中，我们会在将更多数据复制到线路之前等待，直到它低于阈值。这保证了在传输中永远不会有太多数据。如果接收端没有消耗新数据（因为没有可用的缓冲区），这会减慢发送端的速度。

这种固定大小池之间的简单缓冲区流使 Flink 具有强大的背压机制，其中任务产生数据的速度永远不会超过可以消耗的速度。

我们为两个任务之间的数据传输描述的机制自然地推广到复杂的管道，保证背压在整个管道中传播。

让我们看一个简单的实验，它展示了 Flink 在工作中的背压下的行为。我们运行一个简单的生产者-消费者流拓扑，任务在本地交换数据，我们改变任务产生记录的速度。对于此测试，出于演示目的，我们使用比默认值更少的内存来使背压效果更加明显。我们为每个任务使用 2 个大小为 4096 字节的缓冲区。在通常的 Flink 部署中，任务会有更多的更大尺寸的缓冲区，这只会提高性能。该测试在单个 JVM 中运行，但使用完整的 Flink 代码堆栈。

该图显示了生产（黄色）和消费（绿色）任务的平均吞吐量占最大吞吐量（我们在单个 JVM 中每秒达到 800 万个元素）的百分比，因为它随时间变化。为了测量平均吞吐量，我们每 5 秒测量一次任务处理的记录数。

首先，我们以 60% 的全速运行生产任务（我们通过Thread.sleep()模拟减速的情况）。消费者以相同的速度处理数据，我们不会人为地减慢速度。然后我们将消耗任务的速度减慢到其全速的 30%。在这里，背压效应开始发挥作用，因为我们看到生产者也自然地减慢到其全速的 30%。然后我们停止消费者的人为减速，两个任务都达到了它们的最大吞吐量。我们再次将消费者减慢到其全速的 30%，管道立即与生产者做出反应，生产者也减慢到其全速的 30%。最后，我们再次停止减速，两个任务都以 100% 的全速继续。总而言之，我们看到生产者和消费者在管道中遵循彼此的吞吐量，这是流式管道中所需的行为。