在我们Flink Friday Tip的这一集中，我们将逐步说明Apache Flink如何与Apache Kafka协同工作，以确保Kafka主题的记录以一次性保证进行处理。

检查点是Apache Flink的内部机制，可以从故障中恢复。检查点是Flink应用程序状态的一致副本，包括输入的读取位置。如果发生故障，Flink将通过从检查点加载应用程序状态并从恢复的读取位置继续恢复应用程序，就像没有发生任何事情一样。您可以将检查点视为保存计算机游戏的当前状态。如果你在游戏中保存了自己的位置后发生了什么事情，你可以随时回过头再试一次。

检查点使Apache Flink具有容错能力，并确保在发生故障时保留流应用程序的语义。应用程序可以定期触发检查点。

Apache Flink中的Kafka消费者将Flink的检查点机制与有状态运算符集成在一起，其状态是所有Kafka分区中的读取偏移量。触发检查点时，每个分区的偏移量都存储在检查点中。Flink的检查点机制确保所有操作员任务的存储状态是一致的，即它们基于相同的输入数据。当所有操作员任务成功存储其状态时，检查点完成。因此，当从潜在的系统故障重新启动时，系统提供一次性状态更新保证。

下面我们将介绍Apache Flink如何在逐步指南中检查Kafka消费者抵消。在我们的示例中，数据存储在Flink的Job Master中。值得注意的是，在POC或生产用例下，数据通常存储在外部文件存储器（如HDFS或S3）中。

第1步：

下面的示例从Kafka主题中读取两个分区，每个分区包含“A”，“B”，“C”，“D”，“E”作为消息。我们将两个分区的偏移量设置为零。

 

image

第2步：

在第二步中，Kafka消费者开始从分区0读取消息。消息“A”在“飞行中”处理，第一个消费者的偏移量变为1。

 

image

第3步：

在第三步中，消息“A”到达Flink Map Task。两个消费者都读取他们的下一个记录（分区0的消息“B”和分区1的消息“A”）。两个分区的偏移量分别更新为2和1。与此同时，Flink的Job Master决定在源头触发检查点。

 

image

第4步：

在接下来的步骤中，Kafka使用者任务已经创建了状态的快照（“offset = 2,1”），现在存储在Apache Flink的Job Master中。源分别在来自分区0和1的消息“B”和“A”之后发出检查点屏障。检查点障碍用于对齐所有操作员任务的检查点，并保证整个检查点的一致性。消息“A”到达Flink Map Task，而顶级消费者继续读取其下一条记录（消息“C”）。

image

第5步：

此步骤显示Flink Map Task从两个源和检查点接收检查点障碍，其状态为Job Master。与此同时，消费者继续从Kafka分区阅读更多活动。

 

image

第6步：

此步骤显示Flink Map Task在检查其状态后与Flink Job Master进行通信。当作业的所有任务确认其状态为检查点时，作业主管完成检查点。从现在开始，检查点可用于从故障中恢复。值得一提的是，Apache Flink不依赖于Kafka偏移来恢复潜在的系统故障。

 

image

在发生故障时恢复

---

如果发生故障（例如，工作人员故障），则重新启动所有操作员任务，并将其状态重置为上次完成的检查点。如下图所示。

 

image

Kafka源分别从偏移量2和1开始，因为这是完成的检查点的偏移量。当作业重新启动时，我们可以期待正常的系统操作，就好像之前没有发生故障一样。