我比较倾向于是网络原因。但flink的日志目前无法很明显反映和确认。期望有人从flink反压机制角度考虑下，有没有因为网络“抖动”，比如长连接断开等问题导致反压的case。而且这种情况是否会自动恢复呢？从我的几次经验来看我不重启就不恢复。。。
赵一旦 <hinobl...@gmail.com> 于2021年1月6日周三 下午11:43写道： > 如题，反压的原因，不考虑计算压力大，并行度不合理等问题。 > 比如是否可能和网络也有关呢？ > > 考虑如下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后，重启任务。任务运行恢复正常。 > > 从如上来看，也更进一步证明了不是压力问题，否则为什么我重启就没问题了。不重启则是“一直”反压停滞。 > > > > > >
