十六、Flink进阶--Flink checkpoint实现原理

前面我们已经了解过flink的状态，对于这些状态如何保存，我们一起学习一下flink的checkpoint机制，并了解一下rocksdb中的增量checkpoint是怎么实现的。

Checkpoint实现原理

Flink提供的checkpoint机制可以在流任务发生故障时，任务恢复之后，state只被处理一次 exactly once ，当然也可选为 at least once。checkpoint原理就是连续绘制分布式的快照，而且非常轻量级，可以连续绘制，并且不会对性能产生太大影响。默认情况下,checkpoint是关闭的。

Barriers

flink 分布式快照的核心元素是 stream barriers,这些barriers被注入到流中，并作为流的一部分，随着流流动。barriers将数据流的记录分为进入当前快照的记录和进入下一个快照的记录，每个barriers都携带了快照的ID，快照的数据在barriers的前面推送。barriers非常轻量级，不会中断流的流动。同一时间，会有多个checkpoint在并发进行。

barrier被注入到并行流的数据源，注入快照n (称为Sn)的barriers 是数据源中个一个位置，在kafka 就是某个分区的最后一条记录的offset。这个位置Sn后续会汇报给JM的checkpoint coordinator（协调checkpoint功能）。
barrier随着流向下游流动，当中间的operator从他所有的输入流中收到checkpoint n 的barrier时，该operator会将barrier发送给他的下游operator。一旦到达DAG的末端，sink会将这条流的state handle汇报JM的checkpoint coordinator，当sink从他所有的输入流中接收到了checkpoint n barrier ，Jm 会返回一个completed checkpoint meta, 然后checkpoint 标记为完成，状态存储到相应的state backend中。

barrier 对齐

当一个opeator有多个输入流的时候，checkpoint barrier n 会进行对齐，就是已到达的会先缓存到buffer里等待其他未到达的，一旦所有流都到达，则会向下游广播，exactly-once 就是利用这一特性实现的，at least once 因为不会进行对齐，就会导致有的数据被重复处理。

checkpoint 数据结构

当一个operator接收到所有上游发送的 checkpoint n barrier 向下游发送之前，会对状态进行一次快照，将offset state 等值保存起来，默认情况下是保存在Jm的内存中，由于可能会比较大，可以存在状态后端中，生成中建议放hdfs.

到最终checkpoint 快照的完整数据结构类似与一个表格，每个opeator经过处理后填写属于自己的那部分，最后会将其存到state backend中供failover时使用。

RocksDB实现增量checkpoint原理:
state backend中提供了一种RocksDb存储checkpoint ,它是Flink提供的唯一可以实现增量checkpoint的方法。原理是每次生成checkpoint是会生成sst文件（不会再修改了），会和之前的文件进行对比，每次上传新增的sst文件即可,大概就是这样。