【Flink】浅谈Flink背压问题（1）

咱们好，咱们的gzh是向阳三只大明白，满满全是干货，共享近期的学习常识以及个人总结（包含读研和IT），跪求一波重视，期望和咱们一同尽力、前进！！

概述

在多线程的状况下有一个典型的模，型生产者顾客模型，该模型主要由生产者、顾客和一个大小固定的队列组成。生产者向队列发送数据，顾客从队列中取出数据并处理。

针对上述模型，假设队列归于有限长度，当顾客才干<生产者才干的时分就会呈现数据堆积，这样生产者的生产就会中止。现在将这个模型引入Flink算子链中，生产者和顾客的身份是相对的，一个生产者是上游的顾客，一个顾客同样也是下流的生产者。所以一个节点模型中顾客的堵塞将会向上移动，直到源头，这便是反压。

Flink数据通讯模型

假设一个Flink使命（Job）中有 TaskA，TaskB，并发度都是 4，即 A1-A4，B1-B4。TaskA 与 TaskB 运用 keyby 连接。将这个 Flink Job 布置到 2 个 TM 中，每个 TM 分配 2 个 slots。那么Flink会将 $A1,A2,B1,B2$ 放到一个 TM 中，$A3,A4,B3,B4$ 放到一个 TM 中，具体示例如下图所示：

同一个 TM 中的SubTask选用 【local 】办法进行数据传输。位于不同 TM 的 SubTask选用【remote】办法传输。传输示意图如下图所示：

咱们从上图能够看出，以SubTaskA1为例，其数据传输过程如下：

1. TaskA1 先经过 【RecordWriter】目标将数据序列化写到一个 【Output Queue Buffer】 中（下流的并行子使命个数便是队列的个数）。
2. 由【 Netty Service 】进行拉取，满足以下任意一个条件都会进行拉取；
   1. 【Output Queue Buffer】 写满了（默认 32KB）；
   2. 【Output Queue Buffer】 超时了（默认 100ms）；
   3. 遇到特别结构，例如 Barrier，WaterMark；
3. 经过网络传输之后，数据会写到 TaskB3 中的 【Input Queue】 中，然后由 【RecordReader】目标将数据反序列化后进行处理。

也便是说一个 下流TM 中的并行子使命呈现消费延迟，就会堵塞 TCP-channel 进而影响整个 TM 的消费，最终向上传递，导致反压。

反压的监控

Web UI

能够直接在 Flink Web 中进行调查，Flink检测会针对任何一个 Task 做反压检测。该机制需求在 Flink Web 上手动触发，触发后TM 运用 Thread.GetStackTrace 来抽样检测 Task Thread 是否在 NetworkBuffer 中，即是否处于等候状况。根据抽样比例，来判别反压状况。Ratio 是代表抽样 n 次（默认100次）中，遇到等候次数的比例。

• OK：ratio≤0.1；
• LOW：0.01≤Ratio≤0.5;
• High：0.5≤Ratio≤1;

从 Sink→Source 进行查看，第一个反压状况处于 High 的 task 大概率是反压的根源。

该办法有必定的缺点：

1. 因为他是抽样，无法调查到历史数据；
2. 影响作业流程；
3. 高并发场景下，需求等候很久才干检测成功；

Flink Network Metric

在上文提到过，TM之间的通讯都会运用到 InputQueue 和 OutputQueue，咱们能够经过运用【InputQueueUsage】 和 【OutputQueueUsage】这两个指标来判别呈现反压的方位。

现在看一个实践的例子

能够看出 FlatMap→Reduce 呈现了堵塞，再看 reduce 使命的 inpoolusage 和 outpoolusage 指标，得出结论reduce使命便是反压的源头。

往期回顾

1. 【分布式】浅谈CAP、BASE理论（1）

文中难免会呈现一些描绘不当之处（尽管我已反复查看屡次），欢迎在留言区指正，相关的常识点也可进行共享，期望咱们都能有所收成！！我将在下一期详细介绍反压形成的原因以及处理办法，敬请期待！！