flink這一塊主要參照了谷歌發表的論文《the datflow model》，透過視窗+觸發器+增量處理模型，實現了對大規模、無邊界、亂序資料集的實時處理。

即先透過流式處理管道實時計算出一個接近精確的結果(以水印描述事件處理進度)，再透過增量處理模型不斷地動態修正，最終提供一個完全準確的結果。

Flink作為一款大資料流式處理框架，Flink 是基於其 WaterMark (水印)來處理亂序資料的。WaterMark 是一種特殊的訊息記錄，本身有一個時間截屬性，WaterMark 表示所有事件時間小於該水印的時間的記錄都已經到達 Flink 系統，隨後開始觸發計算。

Flink 中資料亂序是指訊息事件雖然按照時間順序產生，但真正進入 Flink 系統處理時，沒有按照產生的時間順序來到。這其中有很多原因，比如網路 IO 傳播，機器故障等等。

Flink 中有三種時間型別，資料攝入到 Flink 的時間、資料處理的時間、資料的產生事件時間。亂序則是使用的資料的事件時間，在使用事件時間時，一般訊息記錄中要有時間欄位屬性，表示資料記錄真實產生的時間。

Flink 中一般視窗操作使用事件時間比較多。每一個視窗其實都有一個開始的時間和結束的時間，當 Flink 視窗運算元的 WaterMark 的時間截大於視窗結束的時間時，這個視窗開始出發。Flink WaterMark 一般會比真實的事件時間延遲個1、2秒，所以當 WaterMark的時間截為 T 時，之後所有小於 T 時間的記錄，都會被丟棄掉，不進入視窗計算。

當訊息記錄進入 Flink 系統時，可以先不對其進行處理，把記錄儲存在 Flink 狀態中。使用 ProcessFuntion 函式，在其中可以註冊 Timer ，比如 5 秒後開始計算，然後從狀態中讀取原來的記錄，根據業務邏輯來編寫具體的函式邏輯。

仔細看Flink中watermark，它能解決資料亂序的問題，想簡單易懂的理解這個原理機制，可以參考spark中結構化流對watermark的描述，這一點要比flink中描述的更清楚，更形象化！

當 Flink 叢集啟動後，首先會啟動一個 JobManger 和一個或多個的 TaskManager。由 Client 提交任務給 JobManager， JobManager 再排程任務到各個 TaskManager 去執行，然後 TaskManager 將心跳和統計資訊彙報給 JobManager。 TaskManager 之間以流的形式進行資料的傳輸。上述三者均為獨立的 JVM 程序。

Client 為提交 Job 的客戶端，可以是執行在任何機器上（與 JobManager 環境連通即可）。提交 Job 後，Client 可以結束程序 （Streaming的任務），也可以不結束並等待結果返回。

JobManager 主要負責排程 Job 並協調 Task 做 checkpoint（分散式快照）。從 Client 處接收到 Job 和 JAR 包 等資源後，會生成最佳化後的執行計劃，並以 Task 的單元排程到各個 TaskManager 去執行。

TaskManager 在啟動的時候就設定好了槽位數（Slot），每個 slot 能啟動一個 Task，Task 為執行緒。從 JobManager 處接收需要 部署的 Task，部署啟動後，與自己的上游建立 Netty 連線，接收資料並處理。