▍前沿
笔者最近回顾自己对Flink技术栈细节的理解,发现对Flink的网络栈、流控与反压这一套机制存在比较大的盲区。虽然平时多次处理过作业反压的问题,但是不完全理解背后的实现显然说不过去。于是专门写一篇总结,站在大佬们的肩膀上彻底搞清楚Flink是怎么做流控与处理反压的。
Flink网络传输的数据流向如下图所示。
Sender在发送数据时,首先写入TaskManager内部的网络缓存,利用Netty进行传输——将待发送的数据存入Netty的ChannelOutboundBuffer,再经由Socket的发送缓存发送出去。Receiver在接收数据时是反过来的,同样要经过3层缓存,即Socket接收缓存→Netty ChannelInboundBuffer→TaskManager网络缓存。要实现流量控制,就是在上面的流程上做文章。
反压(back pressure)就是流式系统中关于处理能力的动态反馈机制,并且是从下游到上游的反馈。下图示出数据流在Flink TaskManager之间流动的逻辑。
可见,一旦因为下游处理能力不足而出现反压,反压信号的传播应该分为两个阶段:一是从下游TaskManager的输入端(InputGate)传播到直接上游TaskManager的输出端(ResultPartition);二是在TaskManager内部从输出端传播到输入端。当然,我们要重点考虑的是跨TaskManager的反压传播,因为它的链路比较长(参考上一节的数据流向图),更有可能成为瓶颈。
下面先来介绍旧版本中的流控和反压机制。
在1.5版本之前,Flink并没有特别地去实现自己的流控机制,而是在传输层直接依靠TCP协议自身具备的滑动窗口机制(大学计算机网络课程必讲)。下面通过实例来复习TCP滑动窗口是如何实现流控的。
接着这个流程分析下去,可以得知Sender最终会无法发送数据(因为Receiver报告Window=0),直到Receiver消费掉缓存中的数据才能继续发送。同时Sender还会定时向Receiver发送ZeroWindowProbe探测消息,保证Receiver能够及时将消费能力报告给Sender。
接下来用实例介绍反压流程。
这样,我们就实现了反压向上游TaskManager的传递。
基于TCP的流控和反压方案有两大缺点:
Flink 1.5+版本为了解决这两个问题,引入了基于Credit的流控和反压机制。它本质上是将TCP的流控机制从传输层提升到了应用层——即ResultPartition和InputGate的层级,从而避免在传输层造成阻塞。具体来讲:
也就是说,Sender和Receiver通过互相告知对方自己的处理能力的方式来精准地进行流控(注意backlog size和credit也是要通过传输层的,不是直接交换的)。接下来仍然通过实例来说明基于Credit的流控和反压流程。
由上可知,反压信号在TaskManager之间不需要再通过传输层随着数据向上反馈,大大降低了反压的延迟。并且也不会因为一个Task反压而阻塞整个Socket链路,能够相当精确地在Task粒度控制流量,不仅轻量级,而且高效。
扫码关注腾讯云开发者
领取腾讯云代金券
Copyright © 2013 - 2025 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号:粤B2-20090059 深公网安备号 44030502008569
腾讯云计算(北京)有限责任公司 京ICP证150476号 | 京ICP备11018762号 | 京公网安备号11010802020287
Copyright © 2013 - 2025 Tencent Cloud.
All Rights Reserved. 腾讯云 版权所有