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的执行过程:
- Job Manager中的Checkpoint Coordinator向所有source端发送触发Checkpoint的通知,并在source端注入barrier事件。
- Source端向下游传递barrier,并将自己的状态异步地写入到持久化存储中。
- Operator接收到source端传递的barrier之后,会对operator的输入流进行对齐barrier,然后向输出流传递barrier,并将自己的状态异步的写入到持久化存储中。
- 当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。