大数据开发：Flink反压机制入门

面对越来越多的流计算场景需求，Flink在大数据技术生态圈当中的热度，可以说是持续上升。在流计算场景下，反压是非常常见的问题，而Flink也有相应的反压机制作为解决方案。今天的大数据开发学习分享，我们就主要来讲讲Flink反压机制入门。

反压backpressure是流式计算中很常见的问题，它意味着数据管道中某个节点成为瓶颈，处理速率跟不上「上游」发送数据的速率，上游需要进行限速。

上面的图代表了是反压极简的状态，说白了就是：下游处理不过来了，上游得慢点，要堵了！

那么下游是怎么通知上游要发慢点的呢？

Flink在一个TaskManager内部读写数据的时候，会有一个BufferPool（缓冲池）供该TaskManager读写使用（一个TaskManager共用一个BufferPool），每个读写ResultPartition/InputGate都会去申请自己的LocalBuffer。

以上图为例，假设下游处理不过来，那InputGate的LocalBuffer是不是被填满了？填满了以后，ResultPartition是不是没办法往InputGate发了？而ResultPartition没法发的话，它自己本身的LocalBuffer也迟早被填满，那是不是依照这个逻辑，一直到Source就不会拉数据了...

这个过程就犹如InputGate/ResultPartition都开了自己的有界阻塞队列，反正“我”就只能处理这么多，往我这里发，我满了就堵住呗，形成连锁反应一直堵到源头上...

上面是只有一个TaskManager的情况下的反压，那多个TaskManager呢？（毕竟我们很多时候都是有多个TaskManager在为我们工作的）

我们再看回Flink通信的总体数据流向架构图：

从图上可以清洗地发现：远程通信用的Netty，底层是TCP Socket来实现的。

所以，从宏观的角度看，多个TaskManager只不过多了两个Buffer（缓冲区）。

按照上面的思路，只要InputGate的LocalBuffer被打满，Netty Buffer也迟早被打满，而Socket Buffer同样迟早也会被打满（TCP本身就带有流量控制），再反馈到ResultPartition上，数据又又又发不出去了...导致整条数据链路都存在反压的现象。

现在问题又来了，一个TaskManager的task可是有很多的，它们都共用一个TCP Buffer/Buffer Pool，那只要其中一个task的链路存在问题，那不导致整个TaskManager跟着遭殃？

在Flink 1.5版本之前，确实会有这个问题。而在Flink 1.5版本之后则引入了credit机制。

从上面我们看到的Flink所实现的反压，宏观上就是直接依赖各个Buffer是否满了，如果满了则无法写入/读取导致连锁反应，直至Source端。

而credit机制，实际上可以简单理解为以「更细粒度」去做流量控制：每次InputGate会告诉ResultPartition自己还有多少的空闲量可以接收，让ResultPartition看着发。如果InputGate告诉ResultPartition已经没有空闲量了，那ResultPartition就不发了。

关于大数据开发学习，Flink反压机制入门，以上就为大家做了大致的介绍了。在现有的大数据技术生态当中，Flink的流计算性能得到普遍认可，而Flink的学习，也需多加重视。