問題導讀
1.Flink與kafka一起如何做Checkpointing ？
2.發生故障，Flink如何恢復的？
3.Kafka consumer offsets存儲在什麼位置？
下面一些詞簡單解釋：
1.檢查點對應Checkpointing
2.主題對應Topic
3.Job對應工作
######################
在我們這篇文章中，我們將逐步說明Apache Flink如何與Apache Kafka協同工作，以確保Kafka主題（Topic）的記錄exactly-once 保證進行處理。
檢查點（Checkpointing ）是Apache Flink的內部機制，可以從故障中恢復。檢查點是Flink應用程序狀態的一致副本，包括輸入的讀取位置。如果發生故障，Flink將通過從檢查點加載應用程序狀態並從恢復的讀取位置繼續恢復應用程序，就像沒有發生任何事情一樣。可以將檢查點視爲保存計算機遊戲的當前狀態。如果你在遊戲中保存了自己的位置後發生了什麼事情，你可以隨時回過頭再試一次。
檢查點（Checkpoints ）使Apache Flink具有容錯能力，並確保在發生故障時保留流應用程序的語義。應用程序可以定期觸發檢查點。
Apache Flink中的Kafka消費者將Flink的檢查點機制與有狀態運算符集成在一起，其狀態是所有Kafka分區中的讀取偏移量。觸發檢查點時，每個分區的偏移量都存儲在檢查點中。 Flink的檢查點機制確保所有operator 任務的存儲狀態是一致的，即它們基於相同的輸入數據。當所有operator 任務成功存儲其狀態時，檢查點完成。因此，當從潛在的系統故障重新啓動時，系統提供一次性狀態更新保證。
下面我們將介紹Apache Flink如何在逐步指南中檢查Kafka消費者offsets。在我們的示例中，數據存儲在Flink的Job Master中。值得注意的是，在POC或production 用例下，數據通常存儲在外部文件存儲器（如HDFS或S3）中。
第一步：
下面的示例從Kafka主題中讀取兩個分區，每個分區包含“A”，“B”，“C”，“D”，“E”作爲消息。 我們將兩個分區的偏移量設置爲零。
第二步：
在第二步中，Kafka消費者開始從分區0讀取消息。消息“A”在 “in-flight”處理，第一個消費者的偏移量變爲1。
第三步：
在第三步中，消息“A”到達Flink Map Task。 兩個消費者都讀取他們的下一個記錄（partition 0的消息“B”和partition 1的消息“A”）。 兩個分區的偏移量分別更新爲2和1。 與此同時，Flink的Job Master決定在源頭觸發檢查點。
第四步：
在接下來的步驟中，Kafka consumer 任務已經創建了狀態的快照（“offset = 2,1”），現在存儲在Apache Flink的Job Master中。 源分別在來自分區0和1的消息“B”和“A”之後發出檢查點barriers 。 檢查點barriers （障礙）用於對齊所有operator 任務的檢查點，並保證整個檢查點的一致性。 消息“A”到達Flink Map Task，而top consumer 繼續讀取其下一條記錄（消息“C”）。
第五步：
此步驟顯示Flink Map Task從兩個源和檢查點接收Checkpoints barriers 。 與此同時，消費者（consumers ）繼續從Kafka分區閱讀更多events 。
第六步：
此步驟顯示Flink Map Task在檢查其狀態後與Flink Job Master進行通信。 當Job 的所有任務確認其狀態爲檢查點時， Job Master 完成檢查點。 從現在開始，檢查點可用於從故障中恢復。 值得一提的是，Apache Flink不依賴於Kafka偏移來恢復潛在的系統故障。
在發生故障時恢復
如果發生故障（例如，worker故障），則重新啓動所有operator任務，並將其狀態重置爲上次完成的檢查點。
Kafka源分別從偏移量2和1開始，因爲這是完成的檢查點的偏移量。 當作業重新啓動時，我們可以期待正常的系統操作，就好像之前沒有發生故障一樣。