自己做网站价格,亚马逊跨境电商简介,分析网站建设发展措施,威海网站建设哪一家文章目录 前言一、原因分析二、解决方案 前言
前面我也有提到#xff0c;发现flink运行一段时间后#xff0c;不再继续消费的问题。这个问题困扰了我非常久#xff0c;一开始也很迷茫。又因为比较忙#xff0c;所以一直没有时间能够去寻找答案#xff0c;只是通过每天重启… 文章目录 前言一、原因分析二、解决方案 前言
前面我也有提到发现flink运行一段时间后不再继续消费的问题。这个问题困扰了我非常久一开始也很迷茫。又因为比较忙所以一直没有时间能够去寻找答案只是通过每天重启的方式去解决。经过分析其实这个问题也很容易找到根源有兴趣就和我一起看下叭 一、原因分析
首先介绍一下这个程序大概流程比较简单。
一个输入源经过一个算子最后开了三个窗口。并行度都写在括号里了。 下面这是一张taskmanager的cpu使用率可以看出到最后要停掉前也没有出现cpu高飘的情况并且心跳依然存在程序还是在继续运行的。 我们从flink运行图上面可以看到反压很严重 矛盾就出现了明明压力很大为何cpu使用率却几乎为0 于是我点开压力最大的哪个window查看subtask的情况找到对应busy为100的subtask 可以看到这个subtask所处理的数据太多了。一开始我也网上很多网友一样认为是key分配失衡的问题但是我修改完代码发现反而失衡更严重了所以我认为不是失衡的问题。而是其中的某个key确实太多了且数据上显示也确实是有一个key量非常大。所以不管用什么方式这个key必然经过hash之后还是一样的也会走到同一个subtask中去。这个无法避免。
二、解决方案
因此我想到的是采用丢失精度的做法。原本我是开了一天的窗口滑动间隔时一小时。 那么既然处理不来方案就是 如果这个key不需要的话通过白名单过滤 加大滑动间隔的做法 使用滚动窗口代替滑动窗口的做法这种案例在网上可以找到很多只是说选择一种合适的办法去处理找到办法之后代码那都是简单的事了。
