反压排查：任务延迟飙升的第一嫌疑人

Source → Map → KeyBy → Aggregate → Sink
                              ↑
                          这里慢了（瓶颈）
                              ↓
              反压传递：Aggregate ← KeyBy ← Map ← Source
              Source被迫降速，整条链路延迟飙升

Task的状态指标：
  backPressuredTimeMsPerSecond > 0 → 有反压

颜色标识：
  🟢 绿色 OK      — 无反压
  🟡 黄色 LOW     — 轻微反压
  🔴 红色 HIGH    — 严重反压

Source(HIGH) → Map(HIGH) → Aggregate(HIGH) → Sink(OK)
                                               ↑
                              Sink是第一个不反压的 → Aggregate是瓶颈
不对，应该看：
Source(HIGH) → Map(HIGH) → Aggregate(OK但busy很高) → Sink(OK)
                              ↑
                   Aggregate忙但不反压 → 它就是瓶颈

场景一：数据倾斜

SubTask[0]: 处理100万/秒 ← 反压
SubTask[1]: 处理1000/秒
SubTask[2]: 处理800/秒

→ KeyBy的Key分布不均匀，某个Key数据量极大
→ 解决：两阶段聚合（DAY 8详讲）

场景二：外部IO慢

// ❌ 同步查询，每条数据等50ms
processElement(Event event) {
    String result = httpClient.get(url);  // 阻塞50ms
}

// ✅ 异步IO，不阻塞
AsyncDataStream.unorderedWait(
    stream,
    new AsyncDatabaseRequest(),
    1000,  // 超时ms
    TimeUnit.MILLISECONDS,
    100    // 最大并发请求数
);

我遇到过Sink写Doris反压。原因是单条写入，每秒只能写200条。改成微批写入（攒1000条或每5秒flush一次）后，吞吐从200条/秒提升到5万条/秒，反压消失。

场景三：Checkpoint导致反压

Checkpoint做快照时会占用IO和网络资源，State大的任务Checkpoint期间容易反压。

解决：
1. 增量Checkpoint（减少写入量）
2. 加大Checkpoint间隔（如从30秒改为60秒）
3. 非对齐Checkpoint（减少Barrier等待时间）

面试加分提示

💡 用真实排查经历回答：

「我排查反压的流程：第一步看Web UI找瓶颈算子——找第一个不反压但busy很高的算子。第二步看SubTask是否均匀——不均匀就是数据倾斜。第三步看是否有外部IO——有则用异步IO或缓存。

我遇到过一次Sink写Doris反压，原因是单条写入太慢。改成微批写入后吞吐提升了250倍。」

📌 总结

记忆点	内容
反压本质	下游慢，压力反向传递到上游
定位方法	找第一个不反压但busy高的算子
数据倾斜	SubTask处理量不均匀
外部IO	同步变异步（AsyncDataStream）
Sink慢	单条写→微批写，吞吐提升百倍

▶ 下一篇预告：DAY 8 数据倾斜处理

---

Wood聊大数据 | 9年大数据老兵，聊技术、聊职场、聊成长

---

小红书正文

Flink任务延迟飙升，第一嫌疑人就是反压。

反压=下游处理不过来，压力反向传到上游，整条链路变慢。

怎么定位瓶颈？不要看哪个算子反压了——反压是从下游往上传的。要找第一个不反压但busy很高的算子，它就是瓶颈源。

四大原因：① 数据倾斜（某些SubTask压力远大于其他）② 外部IO慢（同步查DB阻塞线程）③ Sink吞吐不够（单条写入太慢）④ 资源不足（CPU打满/GC）。

我遇到过Sink写Doris反压。单条写入每秒只能200条。改成微批写入后吞吐从200→5万/秒，反压消失。