Flink作业反压了，下游处理不过来——反压排查和解决思路
先说结论
反压不是病，是症状。真正的病因可能是：数据倾斜、算子处理逻辑太慢、外部系统性能瓶颈（如Sink写入慢）、并行度不够。排查的核心是找到“第一个变慢的算子”。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
反压（Backpressure）是Flink生产环境里最常遇到的问题。它的意思是“下游处理不过来，要求上游慢下来”。表现为吐吐量下降、延迟升高、Checkpoint超时。今天把反压的原理、排查流程和解决方案讲清楚。
反压的传播机制
Flink的反压是基于网络TCP流控的自然反压：
- 下游算子处理慢，接收缓冲区满了
- TCP窗口缩小，上游发送变慢
- 上游算子的输出缓冲区也满了，它自己也变慢
- 逐层传递到Source，整个作业都变慢
打个比方：像高速公路上的堵车，前面堵了后面也走不动。
排查流程：找到“第一个堵点”
步骤一：看Flink Web UI的Backpressure指标
每个Task都有backpressure状态：OK、LOW、HIGH。从Source往下游找，第一个HIGH的算子的下游就是瓶颈——因为反压是从下游往上游传递的。
步骤二：确认瓶颈原因
| 原因 | 表现 | 解决方案 |
|---|---|---|
| 数据倾斜 | 某个Subtask的Records远超其他 | 加盖打散 / rebalance |
| 算子逻辑多 | 所有Subtask都慢 | 优化逻辑 / 提升并行度 |
| Sink写入慢 | Sink算子反压 | 批量写入 / 异步IO / 换更快的存储 |
| 并行度不够 | 所有Subtask CPU近满 | 增加并行度 |
| GC停顿 | 每隔一段时间突然变慢 | 加内存 / 优化状态大小 |
实战经验：Sink性能瓶颈
我在元宇宙社交App做实时平台时，有个作业写Doris时反压严重。排查后发现是Doris的Sink每条数据都发一次HTTP请求（Stream Load），TPS只有几百。
解决方案：改成批量写入——每积累5000条或每5秒刷一次，Tps从几百提升到每秒10万条，反压完全消失。这个经验后来我用在所有的Sink配置上——Sink必须批量写入，不能逐条写。
快速缓解反压的应急手段
如果生产环境反压了需要紧急处理：
- 临时加大并行度（如果资源允许）
- 检查Sink端是否有性能问题（Doris的Compaction、Kafka的Broker负载）
- 临时关闭Checkpoint（减少IO压力，但注意恢复风险）
- 检查是不是GC导致的间歇性反压（看GC日志）
总结
反压是症状不是病因。排查核心是找到“第一个堵点”——看Backpressure指标仏SOURCE往下游找。常见原因：倾斜、算子逻辑慢、Sink写入慢、并行度不够。面试时能说清楚反压的传播机制、排查流程、和一个“Sink改批量写入解决反压”的实战，就很有深度。
第1-5篇完结。下一辑继续聊State管理、Exactly-Once实现、Flink SQL vs DataStream、双流Join、实时数仓架构等实战场景。
你们生产环境遇到过最难排查的反压是什么原因？评论区聊聊～
关注「Wood聊大数据」| 9年大数据老兵，聊技术、聊职场、聊成长