Flink——Flink Checkpoint实现原理

CheckPoint概述

我们知道Flink是通过数据流的重放和Checkpoint机制来实现容错的。一个Checkpoint记录着数据流中某个时刻所有operators对应的状态。Flink的容错机制会对分布式的数据流连续的绘制快照，并将状态进行存储，当因为机器、网络或软件故障等原因导致Flink应用程序失败的时候，数据流可以从最近一次成功的Checkpoint进行恢复，同时通过恢复operators的状态并从Checkpoint的那个点重放记录来保持数据处理的一致性（精确一次的处理）。

需要注意的是：

• 默认情况下，Checkpoint机制是关闭的。
• 需要数据源支持重放功能，比如，Kafka。

Flink容错机制的核心是对分布式数据流和operators状态进行连续的快照，这个机制的灵感来源于 Chandy-Lamport算法，并专门为Flink的执行模型进行了定制。

Checkpoint Barrier

Flink Checkpoint的核心元素就是数据流Barrier，Barrier会被注入到数据流中，作为数据流的一部分向前流动。Barrier将数据流中的数据切分为进入当前Checkpoint的部分和进入下一次Checkpoint的部分，每个Barrier都携带对应Checkpoint的ID。Barrier是非常轻量级的，不会中断数据流的处理。

来自不同Checkpoint的多个Barrier可以同时出现在数据流中，这意味着不同批次的Checkpoint是可以同时发生的。

在执行Checkpoint n时，会在source端将barrier注入到数据流中，Flink Job Manager中会有一个Checkpoint Coordinator来记录每个快照在数据流中的位置信息，比如，source为Kafka，那么这个位置就是对应partition中最新一条记录的offset。

之后，barrier会随着数据流往下流动。当后面的operator从它所有的输入流接收到快照 n的barrier时，它将对应的barrier发送到它所有的输出流中。一旦sink operator从它所有的输入流接收到了快照n的barrier，它就会向Checkpoint Coordinator通知快照执行成功。一旦快照n完成，Flink Job将不再向source端请求触发Checkpoint n之前的记录。

Checkpoint执行过程

下图是官网给出的Checkpoint的执行过程：

1. Job Manager中的Checkpoint Coordinator向所有source端发送触发Checkpoint的通知，并在source端注入barrier事件。
2. Source端向下游传递barrier，并将自己的状态异步地写入到持久化存储中。
3. Operator接收到source端传递的barrier之后，会对operator的输入流进行对齐barrier，然后向输出流传递barrier，并将自己的状态异步的写入到持久化存储中。
4. 当sink端接收到所有输入流传递过来的barrier之后，就会向Checkpoint Coordinator通知，此次Checkpoint执行完成。

Flink在整个Checkpoint的执行过程中，不仅会存储此次Checkpoint的状态数据，同时也存储每个算子的状态数据。

不对齐的Checkpoint

我们上面说的的Checkpoint都是对齐的Checkpoint，也就是说，当operator有多个输入流的时候，它必须要收到所有输入流的barrier之后，才能向下游传递barrier。这就造成operator处于block等待状态，可能会影响整个作业的处理性能。

不过，从Flink 1.11版本开始，Checkpoint也可以不对齐地执行了。这种情况下，Flink同样会在source端注入barrier，但只在sink端进行对齐，中间的operator在接收到barrier之后立即传递给它的下游operator。

参考

• https://ci.apache.org/projects/flink/flink-docs-release-1.12/learn-flink/fault_tolerance.html
• https://ci.apache.org/projects/flink/flink-docs-release-1.12/concepts/stateful-stream-processing.html