在分佈式環境下,Flink將操做的子任務鏈在一塊兒組成一個任務,每個任務在一個線程中執行。將操做鏈在一塊兒是一個不錯的優化:它減小了線程間的切換和緩衝,提高了吞吐量同時減低了時延。這些鏈式行爲是可配置的,詳情請見:chaining docshtml
下圖中的示例以5個子任務來運行,所以有5個併發的線程apache
Flink的運行時環境由兩個進程組成:後端
一個Flink集羣中至少有一臺JobManager節點。高可用性的集羣中將會有多臺JobManager節點,其中有一臺是leader節點,其餘的是備節點(standby)。api
每個集羣中至少有一個TaskManager。緩存
JobManager和TaskManager能夠有多種啓動方式:直接在物理機上以standalone集羣的形式啓動,在容器中啓動以及經過資源管理框架YARN或者Mesos來啓動。TaskManagers與JobManagers進行通訊,發送心跳信息來告知JobManager本身還處於活躍狀態,同時接受JobManager分配的任務。數據結構
Client並非運行時環境或者程序運行的一部分,而是用來準備數據流和將數據流發送到JobManager中。以後client能夠斷開鏈接,或者繼續保持鏈接來接收處理報告。Client要麼做爲觸發執行的Java/Scala程序的一部分,或者是在命令行進程./bin/flink run …中併發
每個worker(TaskManager)是一個JVM進程,並在不一樣的線程中運行着一個或者多個子任務。爲了控制每一個worker可接受的最大任務數,每一個worker須要有個task slots(任務槽)(至少有一個槽)。每個task slot表明着TaskManager的一個固定的資源子集,例如一個TaskManager有三個slot的話,意味着該TaskManager將會分配1/3的資源到每個slot中去。將資源歸入槽中意味着一個任務不會跟做業中的其餘任務競爭託管內存,而是會保留必定的託管內存。注意:如今的slot尚未進行CPU的隔離,當前僅僅進行了託管內存的隔離。框架
經過調整slot的數量,用戶能夠自定義多少個任務之間彼此隔離。一個TaskManager有一個slot意味着每個任務運行在一個獨立的JVM進程中。有多個slot意味着多個任務共享一個JVM進程,共享JVM進程的任務之間共享TCP鏈接和心跳信息,同時共享數據集和數據結構,從而節省了每一個任務的開銷。分佈式
默認狀況下,Flink容許subtask(子任務)之間共享slot,即便不是來自同一個task(任務),只要這些subtask(子任務)來自同一個做業。結果是一個槽能夠持有做業的整個pipeline 。容許slot共享的有兩個好處:優化
一、Flink集羣須要與做業中使用的最高並行度同樣多的任務槽(task slot),不在須要再去計算一個程序中總共包含了多少了task(任務)。
二、使得獲取更好的資源利用率變得更加容易,沒有slot共享的話,非密集型的source/map子任務將會拆分紅與密集型的window子任務同樣多的資源。有了slot共享,就能夠提升任務的併發數,從2個到6個,充分利用了槽的資源,也保證了子任務公平地分佈在TaskManager集羣中。
API中還包括了一個資源組機制,能夠用來防止不須要的slot共享。
根據經驗法則,最好的slot數量配置是跟CPU核數一致,對於超線程,每一個slot能夠分配兩個或者更多的硬件線程上下文。
存儲key/value鍵值索引的切確數據結構取決於所選的state後端。一種state後端是將數據保存在內存的哈希map中 ,另外一種則是以key/value的形式保存在RocksDB中。除了定義保存State的數據結構,State後端還實現了一個邏輯來獲取key/value state的時間點快照並做爲checkpoint的一部分保存起來。
用DataStream API書寫的程序能夠從一個savepoint 中恢復執行。Savepoint容許更新您的程序而不丟失Flink中的任何state信息。
Savepoints是手動觸發checkpoint,獲取程序的快照並將快照寫入到state後端。它們依靠按期的checkpoint機制,在執行過程當中程序在work節點上產生週期性快照,並生成checkpoint。對於故障恢復,只須要最新生成的checkpoint,舊的checkpoint能夠在新的checkpoint生成以後就丟棄掉了。
Savepoints相似於週期性的checkpoint,除了它們是由用戶手動觸發的,而且不會在新的checkpoint生成以後而自動過時。Savepoints能夠經過命令行生成或者在取消一個做業時調用REST API產生。