Apache Flink 如何管理Kafka消费者offsets

问题导读

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开始，因为这是完成的检查点的偏移量。 当作业重新启动时，我们可以期待正常的系统操作，就好像之前没有发生故障一样。