考察点
反压是流处理系统最实际的线上问题，这道题考的是排查能力而非概念背诵。面试官想听到：反压怎么传导、Web UI 上哪些指标看反压、找到反压点之后怎么定位根因。追问会往 credit-based 机制细节、反压与 Checkpoint 的关系、常见根因分类走。
参考答案
反压是怎么传导的
下游处理慢，数据必然在某个环节堆积，堆积逐级往上游蔓延，直到 source 降速——这就是反压。Flink 1.5 之后的传输层用信用额度（credit-based）流控：每个输入通道有一定数量的 buffer 额度，下游每消费一批数据就向上游发放 credit，上游只有在拿到 credit 时才能发送数据。下游处理不过来时不发 credit，上游输出缓冲写满，发送线程被堵住，于是上游自己的处理也慢下来，逐级传导到 source（source 端表现为输出缓冲占满，消费 Kafka 变慢）。
这套机制的好处是没有丢包式的暴力限流，靠 TCP 层之上的应用层流控自然降速，反压状态本身也可以被指标化。
排查套路：先找反压点
第一步看 Web UI 的 Back Pressure 页签：每个 task 有 OK / LOW / HIGH 三档反压状态（通过采样线程栈判断输出是否被堵）。关键规律是：反压状态为 HIGH 的算子是被拖累的，第一个显示 OK 的下游算子往往才是瓶颈源头——它慢，所以上游全堵。沿数据流方向找到「HIGH 变 OK」的分界点。
第二步确认瓶颈算子在忙什么。看这些指标：busyTimeMsPerSecond（算子实际处理时间占比）、idleTimeMsPerSecond、backPressuredTimeMsPerSecond。busy 接近 100% 说明算子真在拼命干活（处理逻辑重或数据倾斜）；busy 不高但反压高，说明在等下游或等 IO。再配合 TaskManager 的线程栈采样（Stack Trace），看 task 线程卡在哪个方法：卡在 RocksDB JNI 调用是状态读写瓶颈，卡在 HTTP 客户端是外部维度关联慢，卡在序列化是数据体积大。
常见根因与对策
- 数据倾斜：个别 subtask 处理量远超同伴，看 Web UI 各 subtask 的 Records Received 分布，倾斜就按倾斜方案处理（加盐打散、两阶段聚合）。
- 状态访问慢：RocksDB 在机械盘或 cache 不足时读写拖慢全链，换 SSD、开托管内存、增并行度摊薄状态。
- 外部系统慢：sink 写不动（MySQL 批量太小、ES 集群抖动）、维度表同步查询超时。对策是异步 IO、攒批写、加缓存。
- GC 停顿：堆状态后端大状态导致 Full GC 卡死一切，看 GC 日志，换 RocksDB 或调堆。
- 资源不足：CPU 打满就是纯粹的算不动，扩容或调并行度。
反压的次生灾害
反压会拖慢 barrier 传播，导致 Checkpoint 对齐时间长甚至超时，容错能力失效——这就是为什么反压必须及时处理，必要时先开非对齐 Checkpoint 保住容错，再慢慢治根因。这个联动关系是面试加分点。
可能的追问
- 反压一定是坏事吗？——瞬态反压是正常的（流量突增、Checkpoint 期间），持续反压才需要处理；反压本质上是系统的自我保护，比堆积到 OOM 强。
- 怎么区分是倾斜还是整体慢？——看同算子不同 subtask 的处理量分布：一两个特别高是倾斜，普遍高是整体能力不够。
- 反压时 source 端会发生什么？——输出缓冲写满后停止 poll Kafka，lag 持续上涨；所以消费 lag 持续上涨且反压高，基本是下游瓶颈而不是 Kafka 问题。