背景
flink中最常见的问题就是反压，这种情况下我们要正确的识别导致反压的真正的源头，本文就简单看下如何正确识别反压的源头
反压的源头
首先我们必须意识到现实中轻微的反压是没有必要去优化的，因为这种情况下是由于偶尔的流量峰值,TaskManager的GC，定时任务，或者网络波动正好触发引起的，我们要优化的是那种出现持续的反压的情况
其次反压是通过JobManager通过对TaskManager进行定时采样判断TaskManager的cpu状态来确定的，如下:
JobManager对多个采样周期的数据进行平均后得到如下参数：
idleTimeMsPerSecond 每秒空闲时间
busyTimeMsPerSecond 每秒繁忙时间
backPressuredTimeMsPerSecond 每秒反压时间
这里需要注意，既然是多个周期内的平均，需要意识到我们有可能处于这种情况，比如上一个采样cpu处于反压状态，下一个采样处于空闲状态,这种情况其实也值得注意
然后反压的定义如下：
OK: 0% <= back pressured <= 10%
LOW: 10% < back pressured <= 50%
HIGH: 50% < back pressured <= 100%
重新回到正题，比如如下的图：
我们看到Source算子和Flat map算子都处于严重的反压状态，那么导致反压的算子是哪一个呢？是Source算子和Flat Map算子本身吗？答案肯定不是，上游的算子反压都是由于下游算子的消费速度跟不上造成的，所以我们需要查看反压算子的下游算子，下游算子中cpu使用100%的那个下游算子几乎就是导致反压的真正源头，比如这里的keyed aggregate→map算子，cpu使用达到了100%，这才是我们需要优化的算子文章来源：https://www.toymoban.com/news/detail-737978.html
PS: flink UI中展示的每个算子的cpu空闲/忙碌/反压值是算子所有算子任务中的最大子任务的cpu空闲/最大子任务的cpu忙碌/最大子任务的cpu反压的值文章来源地址https://www.toymoban.com/news/detail-737978.html
到了这里，关于识别flink的反压源头的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
