其实可以和kafka的pull模型对比下，kafka消费是不断轮训pull。我的认知中flink应该不是吧？ flink应该仅仅是请求 result partition 的时候下游主动去上游请求？ 建立之后应该就是类似一条连接不断读取数据？
yanfei lei <fredia...@gmail.com> 于2022年9月22日周四 11:31写道： > > Hi, > Flink社区有一篇关于Credit-based Flow Control的blog post > <https://flink.apache.org/2019/06/05/flink-network-stack.html#credit-based-flow-control> > ，里面介绍了反压机制的原理和优劣势，希望有帮助。 > > Shammon FY <zjur...@gmail.com> 于2022年9月21日周三 11:43写道： > > > 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 的数据传输,是上游算子推给下游, 还是下游算子拉取上游, 这么设计的考虑是啥呢? > > > > > > > > >
