Flink Credit Based 网络通信

2018-03-02 本文已影响200人我爱火车

本文主要对Flink 1.5中在network stack中引入的credit base模式进行说明。首先，会对flink 1.5之前的通信模型进行简单的说明，然后在对Credit Based网络通信模型进行说明，这样更容易理解为什么需要Credit Based这样的通信模型。

老的网络通信模型

数据生产节点

数据消费节点

接受到数据包msg后，首先向LocalBufferPool申请内存buffer。
申请成功则将msg的内容拷贝到buffer中，并释放msg。
如果申请内存失败，则监听LocalBufferPool中的内存情况（这样当有可用的内存时，会被通知到），并将channel的autoRead属性设置为false（导致发送的端的channel变为不可写状态），同时将当前的msg放到staged的集合中（staged集合用来存储那些申请内存失败的msg），当LocalBufferPool中的有可用内存时会先处理staged中的msg集合，staged中的msg处理完毕后才会将channel的autoRead属性设置为true。

缺点
可以看到在老的网络模型中，数据生成节点只能通过检查当前的channel是否可写来决定自己是否要向消费端发送数据，它对下游数据消费端的真实容量情况一概不知。这就导致，当生成节点发现channel已经不可写的时候，有可能下游消费节点已经积压了很多数据（这些数据最终会被发在staged结合中）。

为了解决老的通信模型中，生成节点对消费节点的真实容量情况一无所知而导致数据积压的情况。Flink引入了Credit Based网络通信模型。简单的说，它的工作方式就是，在数据传输的过程中。消费节点主动告知生成节点它的容量情况，也就是消费节点让生成节点发多少数据，生成节点才发多少数据。

数据生产节点

数据写出流程

数据消费节点

节点接到msg包后，从msg包中拿出backlog值，更具该值判断是否需要从LocalBufferPool中申请新的内存块用于接受数据。
如果backlong >= 消费端当前缓存的buffer数，则想向LocalBufferPool中申请新的内存块。然后再将新申请到的内存块作为credit值的增量通过Credit消息发送到数据生产端。
接着msg被接着处理，从消费端缓存的内存块中取出内存块buffer，并将msg拷贝到buffer中，释放msg。

以上便是Credit Based网络模型的大致过程，为了把主要的流程说清楚省略了很多的细节，包括Credit信息的同步、LocalBufferPool的内存控制等。感兴趣的同学看下下面这些相关的源码，毕竟看代码还是更加清楚些：