flink反压及解决思路和实操

1. 反压原因

反压其实就是 task 处理不过来，算子的 sub-task 需要处理的数据量 > 能够处理的数据量，比如：

当前某个 sub-task 只能处理 1w qps 的数据，但实际上到来 2w qps 的数据，但是实际只能处理 1w 条，从而反压

常见原因有：

任务处理性能出现瓶颈：以消费 Kafka 为例，大概率会出现消费 Kafka Lag
Checkpoint 时间长或者失败：因为某些反压会导致 barrier 需要花很长时间才能对齐，任务稳定性差
整个任务完全卡住。比如在 TUMBLE 窗口算子的任务中，反压后可能会导致下游算子的 input pool 和上游算子的 output pool 满了，这时候如果下游窗口的 watermark 一直对不齐，窗口触发不了计算的话，下游算子就永远无法触发窗口计算了，整个任务卡住

查看WebUI

作业图的 UI 展示，会通过不同颜色和数值代表繁忙和反压的程度可以通过BackPressure查看 subtask 反压情况

还可以查看Flink 任务的 Metrics

我这个是并行度是 4 ，所以会有 0、1、2、3 代表是哪个 subTask（task 下每个并行task），其中看到的比较多的是这两个，outPutUsage 代表发送端 Buffer 的使用率，inPutusage 代表的接收端 Buffer 的使用率

然后就很好定位了，基本上常出现反压的就那么几个算子

还不行就设置pipeline.operator-chaining: false，禁用 operator chains ，这时候一个算子就是一个 task ，在根据定位到具体算子

我们生产环境中，会遇到负载高峰、CheckPoint、作业重启引起的数据积压而导致反压，这种情况反压如果是暂时的，我们可以忽略它

除了定位反压节点，还需要排查原因

我们可以用 Web UI 查看该节点每个 SubTask 的 Record Send 和 Record Received 来看是否数据倾斜，也可以通过 Checkpoint 每个 Subtask 的 state 的 size 大小

在代码提交时设置开启火焰图，然后可以在 Web UI 里面查看

rest.flamegraph.enabled: true #默认 false

纵向是调用链，从下往上，顶部就是正在执行的函数

不是用颜色代表的，而是横向长度，代表出现次数或者说执行时长，某个函数过宽，出现了平顶，那这个函数可能有性能问题

也可能是 TaskManager 的内存引起的 GC 问题，也会导致反压，我们一般使用 G1 回收机制，有可能是 TaskManager JVM 各区内存分配不合理导致频繁的 Full GC

我们可以提交任务时设置打印 GC 日志然后查看Web UI GC 情况或者直接看日志

-Denv.java.opts="-XX:+PrintGCDetails -XX:+PrintGCDateStamps"

很多时候反压就是资源不足导致的，给任务加资源
如果是数据倾斜、算子性能问题之类，那就去解决这些问题
如果确实是流量过大消费不过来，就调大并行度（如果是kafka，需要同时调大kafka分区数）
限制数据源的消费数据速度。比如在事件时间窗口的应用中，可以自己设置在数据源处加一些限流措施，让每个数据源都能够够匀速消费数据，避免出现有的 Source 快，有的 Source 慢，导致窗口 input pool 打满，watermark 对不齐导致任务卡住
关闭 Checkpoint。关闭 Checkpoint 可以将 barrier 对齐这一步省略掉，促使任务能够快速回溯数据。然后等数据回溯完成之后，再将 Checkpoint 打开