Hi
我个人觉得简单的说flink数据传输是pull模型可能会有歧义，一般来讲大家理解的两个模型的执行流程如下
1. push模型
上下游计算任务将初始化网络连接后，上游计算任务直接通过连接不断向下游"push"数据
2. pull模型
上下游计算任务初始化网络连接后，下游计算任务根据自己的计算进度，轮询向上游发送请求“pull”数据，执行下一轮计算
在flink里，上下游交互流程主要分为几个步骤
1. 上游计算任务所在的TM创建一个Netty Server
2. 下游计算任务启动时通过Netty Client跟上游创建连接
3. 下游计算任务向上游发送一个partition
request请求，上游根据request请求创建数据reader，通过reader不断读取数据并通过连接发送数据
4. 上下游计算任务分别有自己的内存池子，用于流控，大概流程如下
a) 下游计算任务根据数据消费内存池子情况，不定期向上游计算任务更新授信(credit)
b) 上游计算任务根据接收到的credit消息，更新本地管理的授信大小
c) 上游计算任务根据本地授信大小不断向下游计算任务发送数据
通过这种方式，在资源足够的情况下，可以保证数据传输是完全流式的，这跟传统的pull模型不同，可能更像是支持授信流控机制的push模型
On Wed, Sep 21, 2022 at 9:43 AM yh z <zhengyunhon...@gmail.com> wrote:
> 你好。 Flink 采用的是 pull 模型。pull 模型的优点在于：1.
> 其具有更好的扩展性（下游的消费者可以根据需求增加，只需要获取到上游的消费位点）； 2. 下游的消费者可以根据需求来调整消费速率；
> 3.网络传输，flink 以前也尝试使用过push模型，且为了节约开销，进程间是复用 TCP连接，一个 task 线程的性能瓶颈将导致整条链路的所有
> task 线程不能接收数据，影响整体的数据消费速率。 push模型的优点：消耗较小，不需要设计机制来一直轮训观察上游节点的数据情况。
>
> Xuyang <xyzhong...@163.com> 于2022年9月9日周五 20:35写道：
>
> > Hi，主要是pull模型：下游主动拉取上游的数据。可以在下游的消费能力达到极限时，通过反压机制，让上游减少生产的数据。
> >
> >
> >
> >
> >
> >
> >
> > --
> >
> > Best！
> > Xuyang
> >
> >
> >
> >
> >
> > 在 2022-09-09 19:04:27，"郑 致远" <zehongzheng2...@hotmail.com> 写道：
> > >各位大佬好
> > >请教下,
> > >flink 的数据传输,是上游算子推给下游, 还是下游算子拉取上游, 这么设计的考虑是啥呢?
> >
>
