hi,你好!欢迎访问本站!登录
本站由网站地图腾讯云宝塔系统阿里云强势驱动
当前位置:首页 - 教程 - 杂谈 - 正文 君子好学,自强不息!

Flink中吸收端反压以及Credit机制 (源码剖析)

2019-11-18杂谈搜奇网78°c
A+ A-

先上一张图团体相识Flink中的反压

 

 

       能够看到每一个task都邑有本身对应的IG(inputgate)对接上游发送过来的数据和RS(resultPatation)对接往下流发送数据, 全部反压机制经由历程inputgate,resultPatation公用一个肯定大小的memorySegmentPool来完成(Flink中memorySegment作为内存运用的笼统,类比bytebuffer), 公用一个pool当吸收上游数据时Decoder,往下流发送数据时Encoder,都邑向pool中要求内存memorySegment 。由于是大众pool,也就是说运行时,当接收的数据占用的内存多了,往下流发送的数据就少了,如许是个什么样的状况呢?

比如说你sink端梗塞了,背压了写不进去,那这个task的resultPatation没法发送数据了,也就没法开释memorySegment了,相应的用于吸收数据的memorySegment就会越来越少,直到吸收数据端拿不到memorySegment了,也就没法吸收上游数据了,既然这个task没法吸收数据了,天然引发这个task的上一个task数据发送端没法发送,那上一个task又反压了,所以这个反压从发作反压的处所,顺次的往上游散布直到source,这个就是flink的天然反压。

从源码来看一下flink是怎样完成的

来到数据吸收的处所StreamInputProcessor.java中processInput()要领中

这里经由历程经由历程handler的getNextNonBlocked()要领猎取到了bufferOrEvent背面就会将这个bufferOrEvent剖析成record数据然后运用用户的代码处置惩罚了

实在这里的handler分为两种

  1. BarrierBuffer    
  2. BarrierTracker

区分主假如barrierbuffer完成了barrier对齐的数据缓存,用于完成一次语义,这里今后随缘更新到容错机制的时刻讲

来看一下getNextNonBlocked()要领

这个看到了经由历程会经由历程上游inputGate猎取数据,详细看一下getNextBufferOrEvent()个中有两个比较主要的挪用

 

 

 先看requestPartitions()

 先遍历了一切的inputchannel然后挪用了requestSubpartition()在个中

 先看一下1处,这里返回了一个Netty的Client来看一下createPartitionRequestClient是怎样竖立的

能够看到源码的形貌,这里实在就是竖立与上游发送数据端的tcp衔接的client端,用来吸收上游数据的

接着

这里假如已竖立TCP衔接就直接拿,与上游还没有竖立tcp衔接的话就会先初始化Client端,经由历程这个connect()要领

来看一下第一次是怎样初始化衔接的

看到这个应当熟习Netty的同砚一眼就相识了,在1处就是Client的详细逻辑了,然后与上游端口竖立衔接

来看一下详细的Client端详细的逻辑,这里最好对netty有肯定的熟悉

  1. 1处是一个用于Encoder 的ChannelOutboundHandler通例的编码器没有什么好说的
  2.  2处是用于Decoder的ChannelinboundHandler通例的解码器没有什么好说的

  3.  3处 这里分为两种Handler,区分主假如在notifyCreditAvailable()要领

       

    PartitionRequestClientHandler: 不带信托机制的

         

      CreditBasedPartitionRequestClientHandler:带credit信托机制的

      

    

     

    这里取出了一切的带有信托的上游inputChannel而且向其相应发送了一个Credit对象

 

那带Credit机制的handler什么时候触发userEventTriggered()来触发向上游发送Credit呢?

先不慌,先来看下client吸收到数据后做了什么,看下Nettyclient端的channelRead()要领(这里只看credit机制的)

 decodeMsg()要领中

decodeBufferOrEvent()要领

在没有Credit机制的PartitionRequestClientHandler中

requestBuffer()要领就是要求memorySegmentPool中的memorySegment

这里不能确保能猎取到,所以会用一个while(true)一向挂着

 在Credit机制的CreditBasedPartitionRequestClientHandler中

 

要求requestBuffer()要领就是要求memorySegmentPool中的memorySegment由于信托机制在要求前就已保证有充足的memorySegment所以不会要求不到,这里要求不到直接就抛非常了

然后OnBuffer( )要领

 1处将将这个buffer到场到了这个receivedBuffers的ArrayDeque中,这里要注重receivedBuffers,这个queue背面会用到(背面处置惩罚数据就是轮回的从这个queue中poll拉数据出来)

这里还要注重onBuffer要领还传入了backlog参数,这里是一个积存的数据量(既发送端还没有发送的且没有猎取到Credit的数据量(buffer为单元)实在就是subpartation中的数据量,发送端会把这个积存量往吸收端发,吸收端会用这个积存量来推断是不是能够发送Credit给上游 )

接着会依据积存的数据量

 

当可用的buffer数 <(挤压的数据量 + 已分配给信托Credit的buffer量) 时,就会向Pool中继承要求buffer,这里要求不到也会一向while构成柱塞反压

然后经由历程notifyCreditAvailable()要领发送Credit,详细来看一下 

 

 

 

可用看到这里就触发了前面说到的向上游发送Credit的要领了

到这里,Nettyclient端的初始化以及Netty的处置惩罚逻辑就讲完了

如今回到最最最先的处所

requestPartition()那边竖立nettyclient后

currentChannel.getNextBuffer()要领中

前面我们说到的NettyClient端channelRead读取数据后会把数据放到一个recivedBuffers的queue中,这里就是去谁人queue中取数据然后返回到我们的 数据吸收的处所StreamInputProcessor.java中processInput()要领中的获得上游数据今后,就是最先实行我们用户的代码了挪用processElement要领了。

然后while(true)最先了下一轮拉取数据然后处置惩罚的历程

  选择打赏方式
微信赞助

打赏

QQ钱包

打赏

支付宝赞助

打赏

  移步手机端
Flink中吸收端反压以及Credit机制 (源码剖析)

1、打开你手机的二维码扫描APP
2、扫描左则的二维码
3、点击扫描获得的网址
4、可以在手机端阅读此文章
未定义标签

本文来源:搜奇网

本文地址:https://www.sou7.cn/282406.html

关注我们:微信搜索“搜奇网”添加我为好友

版权声明: 本文仅代表作者个人观点,与本站无关。其原创性以及文中陈述文字和内容未经本站证实,对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。请记住本站网址https://www.sou7.cn/搜奇网。

发表评论

选填

必填

必填

选填

请拖动滑块解锁
>>