原理解析 | 深入了解Apache Flink的网络协议栈

Credit-based 流量控制可确保发送端已经发送的任何数据，接收端都具有足够的能力(Buffer)来接收。新的流量控制机制基于网络缓冲区的可用性，作为 Flink 之前机制的自然延伸。每个远程输入通道(RemoteInputChannel)现在都有自己的一组独占缓冲区(Exclusive buffer)，而不是只有一个共享的本地缓冲池(LocalBufferPool)。与之前不同，本地缓冲池中的缓冲区称为流动缓冲区(Floating buffer)，因为它们会在输出通道间流动并且可用于每个输入通道。

数据接收方会将自身的可用 Buffer 作为 Credit 告知数据发送方(1 buffer = 1 credit)。每个 Subpartition 会跟踪下游接收端的 Credit(也就是可用于接收数据的 Buffer 数目)。只有在相应的通道(Channel)有 Credit 的时候 Flink 才会向更底层的网络协议栈发送数据(以 Buffer 为粒度)，并且每发送一个 Buffer 的数据，相应的通道上的 Credit 会减 1。除了发送数据本身外，数据发送端还会发送相应 Subpartition 中有多少正在排队发送的 Buffer 数(称之为 Backlog)给下游。数据接收端会利用这一信息(Backlog)去申请合适数量的 Floating buffer 用于接收发送端的数据，这可以加快发送端堆积数据的处理。接收端会首先申请和 Backlog 数量相等的 Buffer，但可能无法申请到全部，甚至一个都申请不到，这时接收端会利用已经申请到的 Buffer 进行数据接收，并监听是否有新的 Buffer 可用。

Credit-based 的流控使用 Buffers-per-channel 来指定每个 Channel 有多少独占的 Buffer，使用 Floating-buffers-per-gate 来指定共享的本地缓冲池(Local buffer pool)大小(可选3)，通过共享本地缓冲池，Credit-based 流控可以使用的 Buffer 数目可以达到与原来非 Credit-based 流控同样的大小。这两个参数的默认值是被精心选取的，以保证新的 Credit-based 流控在网络健康延迟正常的情况下至少可以达到与原策略相同的吞吐。可以根据实际的网络 RRT (round-trip-time)和带宽对这两个参数进行调整。

注释3：如果没有足够的 Buffer 可用，则每个缓冲池将获得全局可用 Buffer 的相同份额(±1)。

▼ 造成反压(2)

与没有流量控制的接收端反压机制不同，Credit 提供了更直接的控制：如果接收端的处理速度跟不上，最终它的 Credit 会减少成 0，此时发送端就不会在向网络中发送数据(数据会被序列化到 Buffer 中并缓存在发送端)。由于反压只发生在逻辑链路上，因此没必要阻断从多路复用的 TCP 连接中读取数据，也就不会影响其他的接收者接收和处理数据。

▼ Credit-based 的优势与问题

由于通过 Credit-based 流控机制，多路复用中的一个信道不会由于反压阻塞其他逻辑信道，因此整体资源利用率会增加。此外，通过完全控制正在发送的数据量，我们还能够加快 Checkpoint alignment：如果没有流量控制，通道需要一段时间才能填满网络协议栈的内部缓冲区并表明接收端不再读取数据了。在这段时间里，大量的 Buffer 不会被处理。任何 Checkpoint barrier(触发 Checkpoint 的消息)都必须在这些数据 Buffer 后排队，因此必须等到所有这些数据都被处理后才能够触发 Checkpoint(“Barrier 不会在数据之前被处理!”)。

但是，来自接收方的附加通告消息(向发送端通知 Credit)可能会产生一些额外的开销，尤其是在使用 SSL 加密信道的场景中。此外，单个输入通道( Input channel)不能使用缓冲池中的所有 Buffer，因为存在无法共享的 Exclusive buffer。新的流控协议也有可能无法做到立即发送尽可能多的数据(如果生成数据的速度快于接收端反馈 Credit 的速度)，这时则可能增长发送数据的时间。虽然这可能会影响作业的性能，但由于其所有优点，通常新的流量控制会表现得更好。可能会通过增加单个通道的独占 Buffer 数量，这会增大内存开销。然而，与先前实现相比，总体内存使用可能仍然会降低，因为底层的网络协议栈不再需要缓存大量数据，因为我们总是可以立即将其传输到 Flink(一定会有相应的 Buffer 接收数据)。

在使用新的 Credit-based 流量控制时，可能还会注意到另一件事：由于我们在发送方和接收方之间缓冲较少的数据，反压可能会更早的到来。然而，这是我们所期望的，因为缓存更多数据并没有真正获得任何好处。如果要缓存更多的数据并且保留 Credit-based 流量控制，可以考虑通过增加单个输入共享 Buffer 的数量。

注意：如果需要关闭 Credit-based 流量控制，可以将这个配置添加到 flink-conf.yaml 中：taskmanager.network.credit-model:false。但是，此参数已过时，最终将与非 Credit-based 流控制代码一起删除。

4.序列号与反序列化

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!