flink（七）反压的原理（别人的博客，自己备份一下）

网络流控

网络流控的作用

如上是一张网络流控的图，Producer的吞吐率是2MB/s，Consumer是1MB/s，此时在网络通信时Producer的速度是比Consumer要快的，有1MB/s的速度差。假定两端都有一个Buffer，Producer端有一个发送用的Send Buffer，Consumer端有一个接收用的Receive Buffer，在网络端的吞吐率是2MB/s，5s后Receive Buffer可能就撑不住了，这时候会面临两种情况：

• 如果Receive Buffer是有界的，这时候新到达的数据只能被丢弃掉了。
• 如果Receive Buffer是无界的，Receive Buffer会持续的扩张，最终会导致Consumer的内存耗尽。

网络流控的实现:静态限速

为了解决这个问题，就需要从网络流控上来解决上下游速度差的问题，传统的做法可以在Producer端实现一个类似Rate Limiter这样的静态限流，Producer的发送速率是2MB/s，经过限流这一层后，往Send Buffer去传数据的时候就会降到1MB/s 了，这样的话Producer端的发送速率跟Consumer端的处理速率就可以匹配起来了，就不会导致上述问题。但是这个解决方案有两点限制：

• 事先无法预估Consumer到底能承受多大的速率。
• Consumer的承受能力通常会动态波动。

网络流控的实现:动态反馈/自动反压

针对静态限速的问题演进到了动态反馈（自动反压）的机制，这需要Consumer能够及时的给Producer做一个feedback，即告知Producer能够承受的速率是多少。动态反馈分为两种：

• 负反馈：接受速率小于发送速率时发生，告知 Producer 降低发送速率
• 正反馈：发送速率小于接收速率时发生，告知 Producer 可以把发送速率提上来

TCP流控机制

TCP包结构

根据上图简单回顾一下TCP包的格式结构。首先，有Sequence number这样一个机制给每个数据包做一个编号，还有ACK number这样一个机制来确保TCP的数据传输是可靠的，除此之外还有一个很重要的部分就是Window Size，接收端在回复消息的时候会通过Window Size告诉发送端还可以发送多少数据。

TCP滑动窗口

TCP的流控是基于滑动窗口的机制，现在有一个Socket的发送端和一个Socket的接收端，发送端的速率是接收端的3倍，这样会发生什么样的一个情况呢？假定初始的时候发送的window大小是3，然后接收端的window大小是固定的，就是接收端的Buffer大小为5。

首先，发送端会一次性发3个packets，将1，2，3发送给接收端，接收端接收后会将这3个packets放到Buffer里。

接收端一次消费1个packet，这时候1就已经被消费了，然后看到接收端的滑动窗口会往前滑动一格，这时候2，3还在Buffer当中，而4，5，6是空出来的，所以接收端会给发送端发送ACK =4，代表发送端可以从4开始发送，同时会将window设置为3（Buffer的大小5减去已经存下的2和3），发送端接收到回应后也会将他的滑动窗口向前移动到4，5，6。

这时候发送端将4，5，6发送，接收端也能成功的接收到Buffer中去。

到这一阶段后，接收端就消费到2了，同样其窗口也会向前滑动一个，这时候Buffer就只剩一个了，于是向发送端发送ACK=7、window =1。发送端收到之后滑动窗口也向前移，但是这个时候就不能移动3格了，虽然发送端的速度允许发3个packets，但是window传值已经告知只能接收一个，所以他的滑动窗口就只能往前移一格到7，这样就达到了限流的效果，发送端的发送速度从3降到1。

再看一下这种情况，这时候发送端将7发送后，接收端接收到，但是由于接收端的消费出现问题，一直没有从Buffer中去取，这时候接收端向发送端发送ACK=8、window=0 ，由于这个时候window = 0，发送端是不能发送任何数据，也就会使发送端的发送速度降为0。这个时候发送端不发送任何数据了，接收端也不进行任何的反馈了，那么如何知道消费端又开始消费了呢？

TCP当中有一个ZeroWindowProbe的机制，发送端会定期的发送1个字节的探测消息，这时候接收端就会把 window的大小进行反馈。当接收端的消费恢复了之后，接收到探测消息就可以将window反馈给发送端端了从而恢复整个流程。TCP就是通过这样一个滑动窗口的机制实现 feedback。

TCP-based反压机制(before V1.5)

大体的逻辑就是从Socket里去接收数据，每5s去进行一次WordCount，将这个代码提交后就进入到了编译阶段。

编译阶段：生成 JobGraph

此时还没有向集群去提交任务，在Client端会将StreamGraph生成JobGraph，JobGraph就是做为向集群提交的最基本的单元。在生成JobGrap的时候会做一些优化，将一些没有Shuffle机制的节点进行合并。有了JobGraph后就会向集群进行提交，进入运行阶段。

运行阶段：调度 ExecutionGraph

JobGraph提交到集群后会生成ExecutionGraph，这时候就已经具备基本的执行任务的雏形了，把每个任务拆解成了不同的SubTask，上图ExecutionGraph中的Intermediate Result Partition就是用于发送数据的模块，最终会将ExecutionGraph交给JobManager的调度器，将整个ExecutionGraph调度起来。从物理执行图可以看到每个Task在接收数据时都会通过一个InputGate负责接收数据，再往前有这样一个ResultPartition负责发送数据，在ResultPartition又会去做分区跟下游的Task保持一致，就形成了ResultSubPartition和InputChannel的对应关系。这就是从逻辑层上来看的网络传输的通道，基于这么一个概念可以将反压的问题进行拆解。

问题拆解：反压传播两个阶段

反压的传播实际上是分为两个阶段的，对应着上面的执行图，一共涉及3个 TaskManager，在每个TaskManager里面都有相应的Task在执行，还有负责接收数据的InputGate，发送数据的ResultPartition，这就是一个最基本的数据传输的通道。在这时候假设最下游的Task（Sink）出现了问题，处理速度降了下来这时候是如何将这个压力反向传播回去呢？这时候就分为两种情况：

• 跨TaskManager，反压如何从InputGate传播到ResultPartition；
• TaskManager内，反压如何从ResultPartition传播到 InputGate。

跨TaskManager数据传输

前面提到，发送数据需要ResultPartition，在每个ResultPartition里面会有分区ResultSubPartition，中间还会有一些关于内存管理的Buffer。

对于一个TaskManager来说会有一个统一的Network BufferPool被所有的Task共享，在初始化时会从Off-heap Memory中申请内存，申请到内存的后续内存管理就是同步Network BufferPool来进行的，不需要依赖JVM GC的机制去释放。有了Network BufferPool之后可以为每一个ResultSubPartition创建Local BufferPool。

如上图左边的TaskManager的Record Writer写了<1，2>这个两个数据进来，因为ResultSubPartition初始化的时候为空，没有Buffer用来接收，就会向Local BufferPool申请内存，这时Local BufferPool也没有足够的内存于是将请求转到Network BufferPool，最终将申请到的Buffer按原链路返还给ResultSubPartition，<1，2>这个两个数据就可以被写入了。之后会将ResultSubPartition的Buffer拷贝到Netty的Buffer当中，最终拷贝到Socket的Buffer将消息发送出去。然后接收端按照类似的机制去处理将消息消费掉。

接下来模拟上下游处理速度不匹配的场景，发送端的速率为2，接收端的速率为1，看一下反压的过程是怎样的。

跨TaskManager反压过程

因为速度不匹配就会导致一段时间后InputChannel的Buffer被用尽，于是会向Local BufferPool申请新的Buffer，这时候可以看到Local BufferPool中的一个Buffer就会被标记为Used。

发送端还在持续以不匹配的速度发送数据，然后就会导致InputChannel向Local BufferPool申请Buffer的时候发现没有可用的Buffer了，这时候就只能向Network BufferPool去申请，当然每个Local BufferPool都有最大的可用的Buffer，防止一个Local BufferPool把Network BufferPool耗尽。这时候看到Network BufferPool还是有可用的Buffer可以向其申请。

一段时间后，发现Network BufferPool没有可用的Buffer，或是Local BufferPool的最大可用Buffer到了上限无法向Network BufferPool申请，没有办法去读取新的数据，这时Netty AutoRead就会被禁掉，Netty就不会从Socket的Buffer中读取数据了。

显然，再过不久Socket的Buffer也被用尽，这时就会将Window= 0发送给发送端（前文提到的TCP滑动窗口的机制）。这时发送端的Socket就会停止发送。

很快发送端的Socket的Buffer也被用尽，Netty检测到Socket无法写了之后就会停止向Socket写数据。

Netty停止写了之后，所有的数据就会阻塞在Netty的Buffer当中了，但是Netty的Buffer是无界的，可以通过Netty的水位机制中的high watermark控制他的上界。当超过了netty的high watermark，Netty就会将其channel置为不可写，ResultSubPartition在写之前都会检测Netty是否可写，发现不可写就会停止向Netty写数据。

这时候所有的压力都来到了ResultSubPartition，和接收端一样他会不断向Local BufferPool和Network BufferPool申请内存。

Local BufferPool和Network BufferPool都用尽后整个Operator就会停止写数据，达到跨TaskManager的反压。

TaskManager 内反压过程

了解了跨TaskManager反压过程后再来看TaskManager内反压过程就更好理解了，下游的TaskManager反压导致本TaskManager的ResultSubPartition无法继续写入数据，于是Record Writer的写也被阻塞住了，因为Operator需要有输入才能有计算后的输出，输入跟输出都是在同一线程执行，Record Writer阻塞了，Record Reader也停止从 InputChannel读数据，这时上游的TaskManager还在不断地发送数据，最终将这个TaskManager的Buffer耗尽。具体流程可以参考下图，这就是TaskManager内的反压过程。

Credit-based反压机制(since V1.5)

TCP-based反压的弊端

在介绍Credit-based反压机制之前，先分析下TCP反压有哪些弊端：

• 在一个TaskManager中可能要执行多个Task，如果多个Task的数据最终都要传输到下游同一TaskManager就会复用同一个Socket进行传输，这个时候如果单个Task产生反压，就会导致复用的Socket阻塞，其余的Task也无法使用传输，checkpoint barrier也无法发出导致下游执行checkpoint的延迟增大。
• 依赖最底层的TCP去做流控，会导致反压传播路径太长，导致生效的延迟比较大。

Credit-based反压过程

这个机制简单理解就是在Flink层面实现类似TCP流控的反压机制来解决上述的弊端，Credit可以类比为TCP的Window机制。

如图所示在Flink层面实现反压机制，就是每一次ResultSubPartition向InputChannel发送消息的时候都会发送一个backlog size告诉下游准备发送多少消息，下游就会去计算有多少的Buffer去接收消息，算完之后如果有充足的Buffer就会返还给上游一个Credit告知他可以发送消息（图上两个ResultSubPartition和InputChannel之间是虚线是因为最终还是要通过Netty和Socket去通信），下面我们看一个具体示例。

假设我们上下游的速度不匹配，上游发送速率为2，下游接收速率为1，可以看到图上在ResultSubPartition中累积了两条消息，10和11，backlog就为2，这时就会将发送的数据<8,9>和backlog = 2一同发送给下游。下游收到了之后就会去计算是否有2个Buffer去接收，可以看到InputChannel中已经不足了这时就会从Local BufferPool和Network BufferPool申请，好在这个时候Buffer还是可以申请到的。

过了一段时间后由于上游的发送速率要大于下游的接受速率，下游的TaskManager的Buffer已经到达了申请上限，这时候下游就会向上游返回Credit =0，ResultSubPartition收到之后就不会向Netty去传输数据，上游TaskManager的Buffer也很快耗尽，达到反压的效果，这样在ResultSubPartition层就能感知到反压，不用通过Socket和Netty一层层地向上反馈，降低了反压生效的延迟。同时也不会将Socket去阻塞，解决了由于一个Task反压导致TaskManager和TaskManager之间的Socket阻塞的问题。

总结与思考

总结

• 网络流控是为了在上下游速度不匹配的情况下，防止下游出现过载
• 网络流控有静态限速和动态反压两种手段
• Flink 1.5 之前是基于TCP流控+bounded buffer实现反压
• Flink 1.5 之后实现了自己托管的credit – based流控机制，在应用层模拟TCP的流控机制

思考

1、有了动态反压，静态限速是不是完全没有作用了？

实际上动态反压不是万能的，我们流计算的结果最终是要输出到一个外部的存储（Storage），外部数据存储到Sink端的反压是不一定会触发的，这要取决于外部存储的实现，像Kafka这样是实现了限流限速的消息中间件可以通过协议将反压反馈给Sink端，但是像ES无法将反压进行传播反馈给Sink端，这种情况下为了防止外部存储在大的数据量下被打爆，我们就可以通过静态限速的方式在Source端去做限流。所以说动态反压并不能完全替代静态限速的，需要根据合适的场景去选择处理方案。

2、作业处理性能上不去导致source端严重积压怎么办？

首先，确定sink端的外部系统是否正常；

正常的情况下，看有无背压；

如果有背压，确定一下背压出现在哪个算子上，然后适当的扩大下游算子的并行度然后观察作业背压是否缓解或者消除。此外，还可以增大Network Buffer的大小，使得task在传输数据时获得更多的buffer缓解背压。

3、背压导致的后果有哪些？

背压会导致ckp barrier无法正常下发，导致ckp超时失败；

背压会影响任务的处理性能。