wordpress网站维护,网页首页设计图片,160 国际英文网站,做网站前提需要什么文章目录 背景分析 问题来了比较一开始的情况解决方式 背景
之前有分析过一次类似问题#xff0c;最终结论是在keyby之后#xff0c;其中有一个key数量特别庞大#xff0c;导致对应的subtask压力过大#xff0c;进而使得整个job不再继续运作。在这个问题解决之后#xff… 文章目录 背景分析 问题来了比较一开始的情况解决方式 背景
之前有分析过一次类似问题最终结论是在keyby之后其中有一个key数量特别庞大导致对应的subtask压力过大进而使得整个job不再继续运作。在这个问题解决之后后续又再次出现了积压的情况针对这个问题进行排查分析。 分析
通过以下这张图可以看到当前它是没有数据积压的。 可以看到source-map-map-sink/map都放在了同一个task中因为Flink的operator chain算子链机制数据是通过调用链接算子的processElement()方法直接将数据推给下游处理了。这里有300个并行度也就是有300个subtask每个算子之间都是一一对应的如果其中一个并行度的源一直没有消费到数据那么它的下游就一样会是空闲的 通过这张图可以看到有的subtask根本就没有在处理数据而有的处理的是大量的数据。那这种肯定不是我们想要的。这种情况资源存在浪费。 在前后并行度不一致的时候task之间就会默认采用rebalance做负载均衡 可以看到这种情况下下游每个task处理的数据是比较平均的在经过均衡之后
问题来了
到了这里就发现了个问题竟然出现了严重的阻塞问题。 但仔细一看并不是所有下游的subtask都是busy。 这种均衡之后部分阻塞的问题经过代码和实际的数据结合分析我得出的结论是有一类数据需要处理的时间是其他数据的几十倍。rebalance是轮询分配的在某几个task接收到大量该类数据导致它的运行压力直线上升进而使得分配到此处时塞不进去了。即导致整体的阻塞。
比较一开始的情况
那么一开始为什么就没有阻塞呢这一下就让人非常费解明明rebalance负载均衡之后应该压力更小更能够消费得过来才对怎么现在就消费不来了呢。 在task中看到这样的日志因为消费不来很多该类topic的数据被丢弃了因为没有阻塞所以其他topic也就都能够正常消费。
解决方式
所以要解决这个问题的根本方式有两种 1、先把同一种数据需要耗费的时间与其他方式耗费时间差距较大的进行缩小差距。 2、优化代码让算子中的效率增加处理每一条数据的时间减小 3、加大资源增加并行度
