Flink正常消费一段时间后，大量反压，看着像卡住了，但又没有报错。

---

前言

前面我也有提到，发现flink运行一段时间后，不再继续消费的问题。这个问题困扰了我非常久，一开始也很迷茫。又因为比较忙，所以一直没有时间能够去寻找答案，只是通过每天重启的方式去解决。经过分析，其实这个问题也很容易找到根源，有兴趣就和我一起看下叭

---

一、原因分析

首先介绍一下这个程序大概流程，比较简单。

一个输入源，经过一个算子，最后开了三个窗口。并行度都写在括号里了。
下面这是一张taskmanager的cpu使用率，可以看出，到最后要停掉前也没有出现cpu高飘的情况，并且心跳依然存在，程序还是在继续运行的。

我们从flink运行图上面可以看到，反压很严重

矛盾就出现了，明明压力很大，为何cpu使用率却几乎为0
于是我点开压力最大的哪个window，查看subtask的情况，找到对应busy为100的subtask

可以看到，这个subtask所处理的数据太多了。一开始我也网上很多网友一样认为是key分配失衡的问题，但是我修改完代码，发现反而失衡更严重了，所以我认为不是失衡的问题。而是其中的某个key确实太多了，且数据上显示，也确实是有一个key量非常大。所以不管用什么方式，这个key必然经过hash之后还是一样的，也会走到同一个subtask中去。这个无法避免。

二、解决方案

因此我想到的是，采用丢失精度的做法。原本我是开了一天的窗口，滑动间隔时一小时。
那么既然处理不来，方案就是
如果这个key不需要的话，通过白名单过滤
加大滑动间隔的做法
使用滚动窗口代替滑动窗口的做法，这种案例在网上可以找到很多，只是说选择一种合适的办法去处理，找到办法之后，代码那都是简单的事了。