定位反压节点 要解决反压首先要做的是定位到造成反压的节点，这主要有两种办法 :
1. 通过 Flink Web UI 自带的反压监控面板；
2. 通过 Flink Task Metrics。
如果处于反压状态，那么有两种可能性：
１. 该节点的发送速率跟不上它的产生数据速率。这一般会发生在一条输入多条 输出的 Operator（比如 flatmap）。
２. 下游的节点接受速率较慢，通过反压机制限制了该节点的发送速率。
如果是第一种状况，那么该节点则为反压的根源节点，它是从 Source Task 到 Sink Task 的第一个出现反压的节点。
如果是第二种情况，则需要继续排查下游节点。
值得注意的是，反压的根源节点并不一定会在反压面板体现出高反压，面板监控的是发送端，如果某个节点是性能瓶颈并不会导致它本身出现高反压，而是 导致它的上游出现高反压。
总体来看，如果我们找到第一个出现反压的节点，那么反压根源要么是就这个节点，要么是它紧接着的下游节点。
分析反压的大致思路是：
如果一个 Subtask 的发送端 Buffer 占用率很高，则表 明它被下游反压限速了；
如果一个 Subtask 的接受端 Buffer 占用很高，则表明它将 反压传导至上游。
反压情况可以根据以下表格进行对号入座 ( 图片来自官网 ):
对于 Flink 1.9 及以上版本，除了上述的表格，我们还可以根据 floatingBuffersUsage/exclusiveBuffersUsage 以及其上游 Task 的 outPoolUsage 来进行进一 步的分析一个 Subtask 和其上游 Subtask 的数据传输。
通常来说，floatingBuffersUsage 为高则表明反压正在传导至上游，而 exclusiveBuffersUsage 则表明了反压是否存在倾斜（floatingBuffersUsage 高、exclusiveBuffersUsage 低为有倾斜，因为少数 channel 占用了大部分的 Floating Buffer）。
分析具体原因及处理
在实践中，很多情况下的反压是由于数据倾斜造成的。
此外，最常见的问题可能是用户代码的执行效率问题（频繁被阻塞或者性能问 题）。
另外 TaskManager 的内存以及 GC 问题也可能会导致反压。
