反压学习 #3

Merged
zeekling merged 1 commits from fanya_xiangie into main 2023-01-04 15:37:03 +00:00
10 changed files with 51 additions and 1 deletions
Showing only changes of commit de2dfef4c6 - Show all commits

Binary file not shown.

Before

Width:  |  Height:  |  Size: 17 KiB

After

Width:  |  Height:  |  Size: 17 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 27 KiB

After

Width:  |  Height:  |  Size: 27 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 52 KiB

After

Width:  |  Height:  |  Size: 52 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 52 KiB

After

Width:  |  Height:  |  Size: 52 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 63 KiB

After

Width:  |  Height:  |  Size: 63 KiB

View File

@ -11,10 +11,60 @@ consumer的摄入速率。
简单来说Flink 拓扑中每个节点Task间的数据都以阻塞队列的方式传输下游来不及消费导致队列被占满后上游的 简单来说Flink 拓扑中每个节点Task间的数据都以阻塞队列的方式传输下游来不及消费导致队列被占满后上游的
生产也会被阻塞,最终导致数据源的摄入被阻塞。 生产也会被阻塞,最终导致数据源的摄入被阻塞。
## 反压的影响
# TCP-based 反压的弊端
![pic](./backpress002.png)
- 单个Task导致的反压会阻断整个TM-TM之间的socket连checkpoint barries也无法发出。
- 反压传播路径长,导致生效时延较大。
# Credit-based 反压
## 反压过程简介
如图所示在 Flink 层面实现反压机制,就是每一次 ResultSubPartition 向 InputChannel 发送消息的时候都会发送一个
backlog size 告诉下游准备发送多少消息,下游就会去计算有多少的 Buffer 去接收消息,算完之后如果有充足的 Buffer
就会返还给上游一个 Credit 告知他可以发送消息(图上两个 ResultSubPartition 和 InputChannel 之间是虚线是因为最
终还是要通过 Netty 和 Socket 去通信),下面我们看一个具体示例。
![pic](./backpress001.png)
假设我们上下游的速度不匹配,上游发送速率为 2下游接收速率为 1可以看到图上在 ResultSubPartition 中累积了两
条消息10 和 11 backlog 就为 2这时就会将发送的数据 <8,9> 和 backlog = 2 一同发送给下游。下游收到了之后
就会去计算是否有 2 个 Buffer 去接收,可以看到 InputChannel 中已经不足了这时就会从 Local BufferPool 和 Network
BufferPool 申请,好在这个时候 Buffer 还是可以申请到的。
过了一段时间后由于上游的发送速率要大于下游的接受速率,下游的 TaskManager 的 Buffer 已经到达了申请上限,这时候
下游就会向上游返回 Credit = 0ResultSubPartition 接收到之后就不会向 Netty 去传输数据,上游 TaskManager 的
Buffer 也很快耗尽,达到反压的效果,这样在 ResultSubPartition 层就能感知到反压,不用通过 Socket 和 Netty 一层
层地向上反馈,降低了反压生效的延迟。同时也不会将 Socket 去阻塞,解决了由于一个 Task 反压导致 TaskManager 和
TaskManager 之间的 Socket 阻塞的问题。
## 反压的理解
Flink拓扑中的每个节点Task间的数据都已阻塞队列的方式传输下游来不及消费导致队列被占满后上游生产也会被阻
塞,最终导致数据源的摄入被阻塞。
反压通常产生于这样的场景:短时间的负载高峰期导致系统接受数据的速率远高于他处理数据的速率。许多日常问题都会导
致反压,例如:垃圾回收可能会导致流入的数据快速堆积,或遇到大促销、秒杀活动导致流量暴增。
# 反压的影响
反压并不会直接影响作业的可用性,它表明作业处于亚健康的状态,有潜在的性能瓶颈并可能导致更大的数据处理延迟。通 反压并不会直接影响作业的可用性,它表明作业处于亚健康的状态,有潜在的性能瓶颈并可能导致更大的数据处理延迟。通
常来说,对于一些对延迟要求不太高或者数据量比较小的应用来说,反压的影响可能并不明显,然而对于规模比较大的 常来说,对于一些对延迟要求不太高或者数据量比较小的应用来说,反压的影响可能并不明显,然而对于规模比较大的
Flink 作业来说反压可能会导致严重的问题。 Flink 作业来说反压可能会导致严重的问题。
反压如果不能正确处理可能会影响到checkpoint时长和state大小甚至可能会导致资源耗尽甚至系统崩溃。
- 影响checkpoint时长barries不会越过普通数据数据处理会被阻塞也可能会导致checkpoint barries流经整个数据管道
的时长变长导致checkpoint的总时长(End to Duration)变长。
- 影响state大小barries对齐时接受到较快的输入管道的barries后他后面数据会被缓存起来单不处理直到较慢的输
入管道的barries也到达这些被缓存的数据会被放到state里面导致checkpoint变大。
这两个影响对于生产环境的作业十分危险的因为checkpoint时保证数据一致性的关键checkpoint时间变长有可能会导致
checkpoint**超时失败**。而state大小同样可能拖慢checkpoint甚至OOM使用Heap-based StateBackend或者物理机内存
使用超过容器资源使用RocksDBStateBackend的稳定性。

BIN
调优/backpress001.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 121 KiB

BIN
调优/backpress002.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 221 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 37 KiB

After

Width:  |  Height:  |  Size: 37 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 135 KiB

After

Width:  |  Height:  |  Size: 133 KiB