開發十年，就只剩下這套架構體系了！ >>>   

1. Flink Barriers

     Flink分散式快照的核心元素是流barriers。 這些barriers被注入資料流並與記錄一起作為資料流的一部分流動。 barriers永遠不會超過記錄，流量嚴格符合要求。 barriers將資料流中的記錄分為進入當前快照的記錄集和進入下一個快照的記錄。 每個barriers

2. Flink Checkpoint的過程

2.1 Barries 對齊過程

(1).   一旦operator從輸入流接收到快照barrier n，它就不能處理來自該流的任何其他記錄，直到它從其他輸入接收到barrier n為止。 否則，它會混合屬於快照n的記錄和屬於快照n + 1的記錄。

(2).  包含barrier n的流資料暫時被Operator擱置。 從這些流接收的記錄不會被處理，而是放入輸入緩衝區。

(3).  一旦最後一個流接收到屏障n，Operator就會向下一個Operator發出所有掛起的流資料，然後自己發出快照n個屏障。

(4).  之後，它將繼續處理來自所有輸入流的記錄，在處理來自流的記錄之前，會優先處理來自輸入緩衝區的記錄。

 2.2 Checkpoint 過程

  State資料包含兩部分資料

• 使用者定義的狀態：這是由轉換函式（如map（）或filter（））直接建立和修改的狀態。   
• 系統狀態：此狀態是指作為運算子計算一部分的資料緩衝區。 此狀態的典型示例是視窗緩衝區，系統在其中收集（和聚合）視窗記錄，直到視窗被評估和逐出。

   State儲存配置見官網

   https://ci.apache.org/projects/flink/flink-docs-release-1.7/ops/state/state_backends.html 

生成的快照資料包含：

• 對於每個並行流資料來源，啟動快照時流中的偏移/位置
• 對於每個運算子，state資料會被作為快照的一部分

 2.3 Exactly Once 和 At Least Once的區別

    由於存在Barriers 對齊的步驟，所以會存在毫秒級別的延遲。如果對實時性要求很高的程式，可以在checkpoint 期間跳過barriers對齊，一旦operator看到每個輸入的barrier，就會繪製檢查點快照。當跳過對齊時，即使在檢查點n的某些檢查點barriers到達之後，operator也會繼續處理所有輸入。這樣，在獲取檢查點n的狀態快照之前，operator還處理屬於檢查點n + 1的元素。在還原時，這些記錄將作為重複記錄出現，因為它們都包含在檢查點n的狀態快照中，並將在檢查點n之後作為資料的一部分進行重放。

     barriers 對齊僅適用於具有多個前驅（連線）的運算子以及具有多個傳送方的運算子（在流repartitioning/shuffle）。因此，資料流在並行流操作（map（），flatMap（），filter（），...）實際上即使在At Least Once模式下也能提供Exactly Once。