在 Flink 中，检测反压（Backpressure）是保障作业稳定性的关键步骤。反压意味着下游算子的处理速度跟不上上游算子的生产速度，导致数据在传输层堆积。

检测 Flink 反压主要有以下三种方式，按推荐程度排序：

---

1. Flink Web UI（最直观、最常用）

从 Flink 1.13 版本开始，Web UI 提供了非常直观的负载分析功能。

A. 概览图中的状态（Busy vs. Backpressured）

在作业的 DAG 图（JobGraph）中，直接观察每个算子的以下两个指标：

• Backpressured（被反压）：表示该算子因为下游处理不过来，导致无法发送数据的时间占比。
  • 如果该值很高（如 100%），说明瓶颈在下游。
• Busy（忙碌）：表示该算子实际在处理数据（计算）的时间占比。
  • 如果该值很高（如 100%），说明瓶颈就是该算子自己（CPU 密集或逻辑复杂）。
• Idle（空闲）：表示该算子在等待上游数据的时间占比。

如何定位瓶颈？
沿着数据流向观察：找到第一个 Backpressured 为低（或 0%） 但 Busy 为高（接近 100%） 的算子。这个算子通常就是反压的源头（瓶颈点）。

B. Back Pressure 选项卡

点击具体的某个 Task，选择 BackPressure 面板。

• 状态指示：
  • OK (绿色): 正常。
  • LOW (黄色): 轻微反压。
  • HIGH (红色): 严重反压。
• 原理：
  • 旧版本 (1.13 之前): 通过周期性触发线程堆栈采样（Stack Trace Sampling）来推断，会有延迟，且对 JobManager 有轻微压力。
  • 新版本 (1.13 及之后): 基于 Task 的 backPressuredTimeMsPerSecond 指标直接计算，更加精准且无额外开销。

---

2. Flink Metrics 指标监控（用于报警和历史回溯）

在生产环境中，你不可能一直盯着 Web UI，通常需要结合 Prometheus + Grafana 进行监控。以下是关键指标：

A. 核心指标

• isBackPressured: (0 或 1) 表示该 Subtask 是否处于反压状态。适合做简单的布尔报警。
• backPressuredTimeMsPerSecond: 每秒钟被反压的毫秒数。这是最准确的量化指标。
• busyTimeMsPerSecond: 每秒钟实际工作（CPU计算/IO）的毫秒数。
• idleTimeMsPerSecond: 每秒钟空闲等待数据的毫秒数。

B. 缓冲区指标 (Network Buffers)

如果想深入网络层分析，可以监控 Buffer 使用情况：

• outPoolUsage: 输出缓冲区的使用率。如果一直很高，说明下游消费慢，数据发不出去（即当前节点被反压）。
• inPoolUsage: 输入缓冲区的使用率。如果一直很高，说明上游发得太快，当前节点处理不过来（即当前节点是瓶颈）。

---

3. 线程堆栈与火焰图 (Flame Graph)

当你通过上述方法定位到具体的瓶颈算子后，需要分析为什么它慢。

• Web UI 火焰图：
  • 在 Web UI 点击该算子 -> 选择 Flame Graph 选项卡。
  • On-CPU: 查看 CPU 主要消耗在哪些用户代码方法上（例如复杂的正则匹配、序列化）。
  • Off-CPU: 查看线程主要阻塞在哪里（例如等待外部数据库响应、锁竞争）。
• Thread Dump:
  • 如果无法使用火焰图，可以在 TaskManager 页面手动 Dump 线程堆栈，查看 RUNNING 状态的线程停留在哪行代码。

---

总结：反压排查流程

1. 看 UI：打开 Flink Web UI，观察 DAG 图。
2. 找源头：寻找 Backpressured 高 的节点的下游，直到找到一个 Busy 高 且 Backpressured 低 的节点。该节点即为瓶颈。
3. 查原因：
   • 如果是 Sink 节点慢：检查外部存储（Kafka/MySQL/HDFS）是否写性能不足或网络延迟。
   • 如果是 Process/Window 节点慢：查看火焰图，分析是代码逻辑复杂（CPU瓶颈）还是频繁访问外部接口（IO瓶颈）。
   • 如果是 GC 问题：检查 TaskManager 的 GC 日志，频繁 Full GC 会导致处理停顿，引发反压。