了解 flink 保存點和檢查點

Question

考慮一個帶有如下管道的 Apache Flink 流應用程序：

Kafka-Source -> flatMap 1 -> flatMap 2 -> flatMap 3 -> Kafka-Sink

其中每個flatMap函數都是無狀態運算符（例如Datastream的普通.flatMap函數）。

檢查點/保存點如何工作，以防傳入消息將在flatMap 3處掛起？ 從flatMap 1開始重新啟動后消息會被重新處理還是會跳到flatMap 3 ？

我有點困惑，因為文檔似乎將應用程序狀態稱為我可以在有狀態運算符中使用的內容，但我的應用程序中沒有有狀態運算符。 “處理進度”是完全保存和恢復的，還是在失敗/重啟后會重新處理整個管道？

關於我之前的問題，失敗（-> flink 從檢查點恢復）和使用保存點手動重啟之間有區別嗎？

我嘗試通過在flatMap 3放置Thread.sleep()並使用保存點取消作業來找出自己（使用EXACTLY_ONCE和 Rocksdb-backend 啟用檢查點）。 然而，這導致flink命令行工具掛起直到sleep結束，即使如此， flatMap 3也被執行，甚至在作業被取消之前發送到接收器。 所以似乎我無法手動強制這種情況來分析 flink 的行為。

如果我上面描述的檢查點/保存點沒有保存/覆蓋“處理進度”，我如何確保到達我的管道的每條消息都永遠不會重新處理任何給定的運算符（平面圖 1/2/3）重啟/失敗情況？

Answer 1

當采取檢查點時，每個任務（操作員的並行實例）都會檢查其狀態。 在您的示例中，三個 flatmap 運算符是無狀態的，因此沒有要檢查點的狀態。 Kafka 源是有狀態的，並檢查所有分區的讀取偏移量。

在失敗的情況下，作業被恢復並且所有任務都加載它們的狀態，這意味着在源操作員的情況下讀取偏移被重置。 因此，應用程序將重新處理自上次檢查點以來的所有事件。

為了實現端到端的恰好一次，您需要一個特殊的接收器連接器，它提供事務支持（例如，用於 Kafka）或支持冪等寫入。