Flink进阶（五）：Flink中的反压问题

有段时间没写flink系列文章了，今天写一写Flink中的反压问题。

何为反压？

在短时间内的负载高峰导致系统接收的数据远大于它能处理数据的速率，如果反压问题不能解决，就会导致系统资源耗尽甚至系统崩溃。那么Flink自身是有反压机制的，它能够自己检测到哪些Operator被阻塞了，然后自适应地降低源头或上游数据的发送速率，从而维持整个系统的稳定。

1.5之前Flink的反压机制

将反压机制之前，先得了解下Flink各个Task之间是如何传递数据的

• Task A 从外部 Source 端读取到数据后将数据序列化放到 Send Buffer 中，再由 Task A 的 Send Buffer 发送到 Task B 的 Receive Buffer；
• Task B 的算子从 Task B 的 Receive Buffer 中将数据反序列后进行处理，将处理后数据序列化放到 Task B 的Send Buffer 中，再由 Task B 的 Send Buffer 发送到 Task C 的 Receive Buffer；
• Task C 再从 Task C 的 Receive Buffer 中将数据反序列后输出到外部 Sink端，这就是所有数据的传输和处理流程。

在Flink1.5之前，反压机制是这样的：

• Task C 由于各种原因吞吐量急剧降低，那么肯定会造成 Task C 的 Receive Buffer 中堆积大量数据，此时 Task B 还在给 Task C 发送数据，但是毕竟内存是有限的，持续一段时间后 Task C 的 Receive Buffer 满了，此时Task B 发现 Task C 的 Receive Buf