我比较倾向于是网络原因。但flink的日志目前无法很明显反映和确认。期望有人从flink反压机制角度考虑下，有没有因为网络“抖动”，比如长连接断开等问题导致反压的case。而且这种情况是否会自动恢复呢？从我的几次经验来看我不重启就不恢复。。。
赵一旦 于2021年1月6日周三 下午11:43写道：
> 如题，反压的原因，不考虑计算压力大，并行度不合理等问题。
> 比如是否可能和网络也有关呢？
>
> 考虑如下case，A->B->C这么一个拓扑，我A（source）结点反压100%，数据彻底不再发送，但B和C都不反压。但是B、C都是非常简单（不可能存在性能问题）。那这还有什么解释吗？
如题，反压的原因，不考虑计算压力大，并行度不合理等问题。
比如是否可能和网络也有关呢？
考虑如下case，A->B->C这么一个拓扑，我A（source）结点反压100%，数据彻底不再发送，但B和C都不反压。但是B、C都是非常简单（不可能存在性能问题）。那这还有什么解释吗？
比如，A和B之间网络是否可能出问题呢？
此外，从机器cpu等监控来看，出现反压后，cpu
idle提升，即反压到cpu利用率直接降低，且cpu在附近实际无升高的迹象。因此不会是瞬间有压力来导致反压。
我当前怀疑和网络有关，有人知道如何确认吗。这种case是否有可能自动恢复呢。
