请教关于是否有除了计算压力以外的反压原因

如题，反压的原因，不考虑计算压力大，并行度不合理等问题。 比如是否可能和网络也有关呢？ 考虑如下case，A->B->C这么一个拓扑，我A（source）结点反压100%，数据彻底不再发送，但B和C都不反压。但是B、C都是非常简单（不可能存在性能问题）。那这还有什么解释吗？

比如，A和B之间网络是否可能出问题呢？

此外，从机器cpu等监控来看，出现反压后，cpu idle提升，即反压到cpu利用率直接降低，且cpu在附近实际无升高的迹象。因此不会是瞬间有压力来导致反压。 我当前怀疑和网络有关，有人知道如何确认吗。这种case是否有可能自动恢复呢。

我最近貌似遇到过好几次类似的case，就是反压到直接不发送数据，整个任务彻底停滞。最终解决方式：1 停任务（而且每次停任务都会有1个task长期处于canceling最终导致tm失败） 2 停ok并且重启tm后，重启任务。任务运行恢复正常。

从如上来看，也更进一步证明了不是压力问题，否则为什么我重启就没问题了。不重启则是“一直”反压停滞。*来自志愿者整理的flink邮件归档