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

但是，在低负载情况下，可能会出现 CPU 使用率和 TCP 数据包速率的增加。这是因为，Flink 将使用任何可用的 CPU 计算能力来尝试维持所需的延迟。一旦负载增加，Flink 将通过填充更多的 Buffer 进行自我调整。由于同步开销减少，高负载场景不会受到影响，甚至可以实现更高的吞吐。

4.2 BufferBuilder 和 BufferConsumer

更深入地了解 Flink 中是如何实现生产者 - 消费者机制，需要仔细查看 Flink 1.5 中引入的 BufferBuilder 和 BufferConsumer 类。虽然读取是以 Buffer 为粒度，但写入它是按 Record 进行的，因此是 Flink 中所有网络通信的核心路径。因此，我们需要在任务线程(Task thread)和 Netty 线程之间实现轻量级连接，这意味着尽量小的同步开销。你可以通过查看源代码获取更加详细的信息。

5. 延迟与吞吐

引入网络 Buffer 的目是获得更高的资源利用率和更高的吞吐，代价是让 Record 在 Buffer 中等待一段时间。虽然可以通过 Buffer 超时给出此等待时间的上限，但可能很想知道有关这两个维度(延迟和吞吐)之间权衡的更多信息，显然，无法两者同时兼得。下图显示了不同的 Buffer 超时时间下的吞吐，超时时间从 0 开始(每个 Record 直接 Flush)到 100 毫秒(默认值)，测试在具有 100 个节点每个节点 8 个 Slot 的群集上运行，每个节点运行没有业务逻辑的 Task 因此只用于测试网络协议栈的能力。为了进行比较，我们还测试了低延迟改进(如上所述)之前的 Flink 1.4 版本。

如图，使用 Flink 1.5+，即使是非常低的 Buffer 超时(例如1ms)(对于低延迟场景)也提供高达超时默认参数(100ms)75% 的最大吞吐，但会缓存更少的数据。

6.结论

了解 Result partition，批处理和流式计算的不同网络连接以及调度类型，Credit-Based 流量控制以及 Flink 网络协议栈内部的工作机理，有助于更好的理解网络协议栈相关的参数以及作业的行为。后续我们会推出更多 Flink 网络栈的相关内容，并深入更多细节，包括运维相关的监控指标(Metrics)，进一步的网络调优策略以及需要避免的常见错误等。

（编辑：核心网）

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