Flink

在 Flink 中需要端到端精準一次處理的位置有三個：

Flink 端到端精準一次處理

Source 端：數據從上一階段進入到 Flink 時，需要保證消息精準一次消費。

Flink 內部端：這個我們已經了解，利用 Checkpoint 機制，把狀態存盤，發生故障的時候可以恢復，保證內部的狀態一致性。不了解的小伙伴可以看下我之前的文章：

Flink可靠性的基石－checkpoint機制詳細解析

Sink 端：將處理完的數據發送到下一階段時，需要保證數據能夠準確無誤發送到下一階段。

在 Flink 1．4 版本之前，精準一次處理只限于 Flink 應用內，也就是所有的 Operator 完全由 Flink 狀態保存并管理的才能實現精確一次處理。但 Flink 處理完數據后大多需要將結果發送到外部系統，比如 Sink 到 Kafka 中，這個過程中 Flink 并不保證精準一次處理。

在 Flink 1．4 版本正式引入了一個里程碑式的功能：兩階段提交 Sink，即 TwoPhaseCommitSinkFunction 函數。該 SinkFunction 提取并封裝了兩階段提交協議中的公共邏輯，自此 Flink 搭配特定 Source 和 Sink（如  Kafka 0．11 版）實現精確一次處理語義（英文簡稱：EOS，即 Exactly－Once Semantics）。

Flink端到端精準一次處理語義（EOS）

注：以下內容適用于 Flink 1．4 及之后版本

對于 Source 端：Source 端的精準一次處理比較簡單，畢竟數據是落到 Flink 中，所以 Flink 只需要保存消費數據的偏移量即可， 如消費 Kafka 中的數據，Flink 將 Kafka Consumer 作為 Source，可以將偏移量保存下來，如果后續任務出現了故障，恢復的時候可以由連接器重置偏移量，重新消費數據，保證一致性。

對于 Sink 端：Sink 端是最復雜的，因為數據是落地到其他系統上的，數據一旦離開 Flink 之后，Flink 就監控不到這些數據了，所以精準一次處理語義必須也要應用于 Flink 寫入數據的外部系統，故這些外部系統必須提供一種手段允許提交或回滾這些寫入操作，同時還要保證與 Flink Checkpoint 能夠協調使用（Kafka 0．11 版本已經實現精確一次處理語義）。

我們以 Flink 與 Kafka 組合為例，Flink 從 Kafka 中讀數據，處理完的數據在寫入 Kafka 中。

為什么以Kafka為例，第一個原因是目前大多數的 Flink 系統讀寫數據都是與 Kafka 系統進行的。第二個原因，也是最重要的原因 Kafka 0．11 版本正式發布了對于事務的支持，這是與Kafka交互的Flink應用要實現端到端精準一次語義的必要條件。

當然，Flink 支持這種精準一次處理語義并不只是限于與 Kafka 的結合，可以使用任何 Source／Sink，只要它們提供了必要的協調機制。

Flink 與 Kafka 組合

Flink 應用示例

如上圖所示，Flink 中包含以下組件：

一個 Source，從 Kafka 中讀取數據（即 KafkaConsumer）

一個時間窗口化的聚會操作（Window）

一個 Sink，將結果寫入到 Kafka（即 KafkaProducer）

若要 Sink 支持精準一次處理語義（EOS），它必須以事務的方式寫數據到 Kafka，這樣當提交事務時兩次 Checkpoint 間的所有寫入操作當作為一個事務被提交。這確保了出現故障或崩潰時這些寫入操作能夠被回滾。

當然了，在一個分布式且含有多個并發執行 Sink 的應用中，僅僅執行單次提交或回滾是不夠的，因為所有組件都必須對這些提交或回滾達成共識，這樣才能保證得到一個一致性的結果。Flink 使用兩階段提交協議以及預提交（Pre－commit）階段來解決這個問題。