原视频链接：https://www.bilibili.com/video/BV124411P7V9?from=search&seid=9418346389470156429
写出到Storage，kafka 有限流机制，但在整个ES端，它的Socket都发生得太慢了，可能ES内部没有很好的限流机制，没有办法把反压传播回来，而是比较暴力地整个socket都无法连接了，可能是它内部负载非常高，瞬间给它非常高的压力，它没有把这个压力通过反压机制给传回来。
怎么处理？
即使有动态反压，但为了防止storage在大的数据量下崩溃，可以在Source端做静态的限流。假设我们知道整个系统的负载，可以尝试在Source端做一些调优，在source端做一些限流的措施。
flink 1.8里 kafka的Source 是可以支持限流的。可以set kafka 的 consumer 我的每秒钟不能超过多少的一个消费（setRate 方法。在提交作业前，这个rate就静态写死了。SparkStreaming 里面也有类似的机制去配置）。这样和反压结合在一起就可以达到一个很好的作用。静态限流和动态反压不是相互替代的关系，也不是说有了动态反压，静态限流就完全没有作用了。
Q & A：
假定说集群反压，task manager 假死了，没有反应了，有没有好的解决办法？
A：什么样的情况会导致 task manager 假死呢？假定 task A显示的是反压状态on high，A的两个下游节点反压状态都显示是ok 的，此时应该调大B 的并行度还是C的并行度？
A：这个情况很明显是说A的发送速度太快了，很明显要调整一下A了，或者把下游B和C的并行度调高，因为可能下游支撑不住了。调高之后再观察一下，下游的B和C有没有反压的情况。首先它俩都是ok的，那么很可能反压是他俩来导致的。上游如果停止发送，下游消费完后，是如何通知上游继续发送的？
A：和TCP类似，也是有一个探测机制的。背压主要出现在哪些节点，如何解决?主要通过增大资源并发吗？
A：其实不一定。通常我们遇到的场景都是Storage撑不住了导致的背压。比如整个流处理完后，是要往Kafka去写的，那么在Kafka 这个topic 的时候都是有做一些限流的措施的，这个时候，Storage撑不住了，就会导致反压给到Sink，Sink给到整个流里面来，这个时候，仅仅去增加并发其实是没有用的，我们真正的瓶颈是在Storage这一层，所以我们产生反压后要去看，不是说一定要去增大并发，而是我们要去调查一下，到底是什么原因导致的反压，可以看下反压的源头是在哪里：
如果说反压源头不是在Sink这一级，比如在FlatMap这一级的话，那我们可以尝试增大FlatMap的并发；
但如果我们发现是最后一个task，在sink这一级出现了一个反压，那我们就要怀疑一下是不是下游的Storage撑不住了导致的反压。
5.taskManager 内部导致的生产与消费不匹配的情况：
A：这个也是有可能的，比如在同一个operator chain内部的话，会有多个operator都在同时去执行，其实每个operator执行的速度也是不一样的。同一个taskManager内部是通过内部的channel去传输的（在同一个线程里面），不是走的network buffer，如果下游的消费太慢了，上游的写应该速度会被降下来，它内部应该不会出现假死的情况。
