反压有问题怎么办？

假设任务逻辑为 A => B => C 这样的task序列，其中B是window类型task，使用时间滚动窗口，假设滚动窗口为5min。

A是Kafka数据源，数据qps很平滑。

B是window类任务，5min滚动窗口，比如0-5分的数据会在6min触发窗口输出。即B的输入是平滑的，但B的输出是集中在6min的（此处以及后续都以0-5min窗口做示例说明）。

C是基于B输出的5min特征的一个计算类task，且复杂性也比较高。

总结即： A --平滑输出---> B ---窗口触发集中输出--> C（计算复杂）

对于0-5min数据，由于B输出集中在6min，且C本身的计算也比较复杂。因此6min时，C task的busy值很容易升高。

C task busy，进而导致B被反压，即B的backpress值很高。

此时我想知道的是，对于B来说，如果B在6min时候输出很快输出到了C，那么没有残留，此时B虽然被反压，但本质不应该影响B继续处理A输出的数据。

即使B在6min时的数据无法很快输出到C，即输出一部分就开始处于反压状态。

但B0-5分的窗口的触发以及触发后的输出可以卡着，我想知道B的输入是否也可能卡住。

为什么需要考虑这个呢，是因为我认为这种情况下，B继续处理5-10分的数据只会影响B的窗口状态，并不会导致B新增更多输出。所以我更期望此时不影响B处理A的输出，即B的反压不传播到A。

想问问了解的大佬们，这种情况B的反压是否会传播到A呢？当一个task被反压到100%，是无脑传播到上游，导致上游也反压呢？

还是独立的逻辑，比如B的输入buffer本身还是可以及时处理掉的，只是B无法输出而已。因此，B并不会导致A反压呢？*来自志愿者整理的flink邮件归档