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

由于通过 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.序列号与反序列化

（编辑：西安站长网）

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