【譯】A Deep-Dive into Flink's Network Stack（1）

Flink的網絡堆棧是組成flink-runtime模塊的核心組件之一，是每一個Flink工做的核心。 它鏈接全部TaskManagers的各個工做單元（子任務）。 這是您的流式傳輸數據流經的地方，所以，對於吞吐量和您觀察到的延遲，Flink做業的性能相當重要。 與經過Akka使用RPC的TaskManagers和JobManagers之間的協調通道相比，TaskManagers之間的網絡堆棧依賴於使用Netty的低得多的API。

這篇博文是關於網絡堆棧的一系列帖子中的第一篇。 在下面的部分中，咱們將首先深刻了解流操做符所呈現的抽象，而後詳細介紹Flink的物理實現和各類優化。 咱們將簡要介紹這些優化的結果以及Flink在吞吐量和延遲之間的權衡。 本系列中的將來博客文章將詳細介紹監控和指標，調整參數和常見的反模式。

邏輯視圖

Flink的網絡堆棧在相互通訊時爲子任務提供如下邏輯視圖，例如在keyBy（）要求的網絡混洗期間。

它抽象瞭如下三個概念的不一樣設置：

• 子任務輸出類型（ResultPartitionType）： 

1.  流水線的（有界的或無界的）：一旦產生數據就能夠向下遊發送，多是一個接一個地，做爲有界或無界的記錄流。
2.  阻塞：僅在生成完整結果時向下遊發送數據。

• 調度類型：

1.  一次性（急切）：同時部署做業的全部子任務（用於流應用程序）。
2.  第一個輸出的下一個階段（懶惰）：一旦任何生產者生成輸出，就當即部署下游任務。
3.  完整輸出的下一個階段：當任何或全部生產者生成完整輸出集時，部署下游任務

• 傳輸：

1. 高吞吐量：Flink不是一個一個地發送每一個記錄，而是將一堆記錄緩衝到其網絡緩衝區中並徹底發送它們。這下降了每一個記錄的成本並致使更高的吞吐量。
2. 經過緩衝區超時的低延遲：經過減小發送未徹底填充的緩衝區的超時，您可能會犧牲吞吐量來延遲

咱們將在下面的部分中查看吞吐量和低延遲優化，這些部分將查看網絡堆棧的物理層。 對於這一部分，讓咱們詳細說明輸出和調度類型。 首先，重要的是要知道子任務輸出類型和調度類型是緊密交織在一塊兒的，只能使二者的特定組合有效。

流水線結果分區是流式輸出，須要實時目標子任務才能發送數據。 能夠在生成結果以前或首次輸出時安排目標。 批處理做業生成有界結果分區，而流式處理做業產生無限結果。

批處理做業也可能以阻塞方式產生結果，具體取決於所使用的運算符和鏈接模式。 在這種狀況下，必須先生成完整的結果，而後才能安排接收任務。 這容許批處理做業更有效地工做而且資源使用更少。

批處理做業也可能以阻塞方式產生結果，具體取決於所使用的運算符和鏈接模式。 在這種狀況下，必須先生成完整的結果，而後才能安排接收任務。 這容許批處理做業更有效地工做而且資源使用更少。

下表總結了有效組合：

1目前Flink未使用。

2批量/流式統一完成後，這可能適用於流式做業。

此外，對於具備多個輸入的子任務，調度以兩種方式啓動：在全部或在任何輸入生成器生成記錄/其完整數據集以後。 要調整批處理做業中的輸出類型和調度決策，請查看ExecutionConfig #setExecutionMode（） - 特別是ExecutionMode  - 以及ExecutionConfig #setDefaultInputDependencyConstraint（）

物理運輸

爲了理解物理數據鏈接，請回想一下，在Flink中，不一樣的任務能夠經過插槽共享組共享相同的插槽。 TaskManagers還能夠提供多個插槽，以容許將同一任務的多個子任務安排到同一個TaskManager上。

未完待續