Flink作业卡顿？一文搞定反压排查和优化

在实时数据处理场景中，Apache Flink 凭借其高吞吐、低延迟的特性成为流式计算的首选框架。然而，许多开发者都遇到过这样的问题：Flink作业突然变慢，数据处理延迟飙升，甚至任务频繁失败等情况——这很可能是反压（Backpressure）在作祟！

本文将从反压原理出发，结合案例，分享如何排查和优化的策略。

在 Apache Flink 中，反压（Backpressure） 是一种流量控制机制，用于解决数据流处理中生产者（上游任务）速度超过消费者（下游任务）处理能力的问题。当系统出现反压时，Flink 会自动调整数据流动，避免下游任务因过载而崩溃或产生高延迟。

·正面作用： 防止系统因过载崩溃，保障稳定性。

·负面作用：可能导致任务不稳定, 出现吞吐量下降、延迟增加，作业停滞，发生failover,  OOM等情况。

当出现反压的时候, 如果任务稳定, 并且数据时效性在业务的容忍范围内可以不做处理。因为反压造成频繁failover 、数据时效性降低、长时间的数据滞留(滞留时间越长,恢复成本就越高)等负面情况, 影响业务的正常运转就需要处理。

Flink 通过基于信用（Credit-Based）的流量控制实现反压。

信用（Credit）：下游任务会向上游任务声明自己还能接收多少数据（类似 TCP 滑动窗口）。初始信用值由下游任务的空闲缓冲区大小决定。每处理完一批数据，下游会向上游发送新的信用值。

关键步骤解析

1.信用初始化

下游Task启动时向上游申请初始信用（如10个Buffer配额）。

2.数据发送阶段

上游每发送1个数据包占用1个Buffer，信用值减1。

下游消费后通过ACK消息返还信用（每消费1个Buffer返还1信用）。

3.反压触发条件

当下游处理变慢→信用耗尽（Credit=0）→上游停止发送数据。

下游通过BackPressureSample线程检测堆栈是否阻塞，确认反压状态。

4.恢复机制

下游处理能力恢复后，主动推送新信用值到上游，重新激活数据流。

反压如何从下游向上游传播？

反压会从最慢的算子（瓶颈点）向源头（Source）逐级反向传播：

1.Sink 算子写入慢（如数据库延迟）→ 积压数据。

2.下游算子处理慢（如窗口聚合）→ 输入缓冲区填满。

3.上游任务检测到下游无信用→ 停止发送数据。

4.最终 Source 降低数据摄入速率（如 Kafka Consumer 暂停拉取消息）。

Flink Web 界面提供了一个选项卡来监控正在运行 jobs 的反压行为。

WebUI 集合了所有 subTasks 的反压和繁忙指标的最大值，并在 JobGraph 中将集合的值进行显示。除了显示原始的数值，tasks 也用颜色进行了标记，使检查更加容易。

在 Job Overview 旁的 Back Pressure 选项卡中，你可以找到更多细节指标。

如果你看到 subtasks 的状态为 OK 表示没有反压。HIGH 表示这个 subtask 被反压。状态用如下定义：

·OK: 0% <= 反压比例 <= 10%

·LOW: 10% < 反压比例 <= 50%

·HIGH: 50% < 反压比例 <= 100%

除此之外，你还可以找到每一个 subtask 被反压、闲置或是繁忙的时间百分比。

Flink 提供了一些内置的metric指标用于监控任务的反压信息。

关键指标：inPoolUsage、outPoolUsage、isBackPressured 、latency。

由于实时任务的特殊性, 任务时启动正常之后, 一般都是7*24h运行, 一般要满足以下场景。

·要可以实时查看任务状态, 当任务异常可以通过监控页面辅助排查, 提升定位问题的效率。

·要支持不同的告警规则, 根据任务的优先级可以配置不同的告警策略。当任务异常时可以主动感知, 而不是下游用户或者数据不准确的时候被动感知。

下面排列几种常见的原因。

现象: flink任务出现数据滞留、 出现反压情况。

排查步骤:

1.  收到Flink任务异常报警之后，一般首先查看监控页面，观察任务的运行情况，通过观察发现GC指标无明显异常,  但是有数据滞留量增多, 反压的情况。

·window算子处于busy状态, 是性能瓶颈点。但是没有反压。