Flink 容错机制 保存点和检查点

配置检查点

//配置检查点
env.enableCheckpointing(180000); // 开启checkpoint 每180000ms 一次
env.getCheckpointConfig().setMinPauseBetweenCheckpoints(50000);// 确认 checkpoints 之间的时间会进行 50000 ms
env.getCheckpointConfig().setCheckpointTimeout(600000); //设置checkpoint的超时时间 即一次checkpoint必须在该时间内完成 不然就丢弃
env.getCheckpointConfig().setCheckpointingMode(CheckpointingMode.EXACTLY_ONCE);//设置有且仅有一次模式 目前支持EXACTLY_ONCE/AT_LEAST_ONCE
env.getCheckpointConfig().setMaxConcurrentCheckpoints(1);// 设置并发checkpoint的数目
env.getCheckpointConfig().setCheckpointStorage("hdfs:///flink-checkpoints/oracle/AC_SUB_REGIST_INFO"); // 这个是存放到hdfs目录下
env.getCheckpointConfig().enableExternalizedCheckpoints(CheckpointConfig.ExternalizedCheckpointCleanup.RETAIN_ON_CANCELLATION);// 开启在 job 中止后仍然保留的 externalizedcheckpoints
env.getCheckpointConfig().enableUnalignedCheckpoints();// 开启checkpoints

从检查点恢复数据

linux>flink run -yd -m yarn-cluster -shdfs:///flink-savepoints/oracle/xx -c xx(目录名).xx(class名) -yD yarn.provided.lib.dirs="hdfs:///flink/lib" /xx/xx.jar

配置保存点

linux>bin/flinksavepoint :jobId [:targetDirectory]

例子：linux>flinksavepoint jobId hdfs:///flink-savepoints/xx-yid yarnjobId

从保存点恢复数据

linux>flink run -yd -m yarn-cluster -shdfs:///flink-savepoints/oracle/xx -c xx(目录名).xx(class名) -yD yarn.provided.lib.dirs="hdfs:///flink/lib" /xx/xx.jar

详细讲解

检查点（Checkpoint）

flink将之前某个时间点所有的状态保存下来，这份存档就是所谓的检查点（checkpoint）。检查点是 Flink 容错机制的核心。检查是针对故障恢复的结果而言的：故障恢复之后继续处理的结果，应该与发生故障前完全一致。所以有时又会把 checkpoint 叫作一致性检查点。

检查点的保存

（1） 周期性的触发保存

  检查点作为应用状态的一份存档，其实就是所有任务状态在同一时间点的一个快照（snapshot），它的触发是周期性的。每隔一段时间检查点保存操作被触发时，就把每个任务当前的状态复制一份，按照一定的逻辑结构放在一起持久化保存起来，就构成了检查点

（2） 保存的时间点

  当所有任务都恰好处理完一个相同的输入数据的时候，将它们的状态保存下来。首先，这样避免了除状态之外其他额外信息的存储，提高了检查点保存的效率。其次，一个数据要么就是被所有任务完整地处理完，状态得到了保存；要么就是没处理完，状态全部没保存：这就相当于构建一个事务（transaction）。如果出现故障，恢复到之前保存的状态，故障时正在处理的所有数据都需要重新处理；所以只需要让源（source）任务向数据源重新提交偏移量、请求重放数据就可以了。这需要源任务可以把偏移量作为算子状态保存下来，而且外部数据源能够重置偏移量；（典型应用 Kafka）

从检查点恢复状态

当发生故障时，需要找到最近一次成功保存的检查点来恢复状态

具体的步骤为：

（1）重启应用

  遇到故障之后，第一步当然是重启，所有任务的状态会清空

（2）读取检查点，重置状态

  找到最近一次保存的检查点，从中读出每个算子任务状态的快照，分别填充到对应的状态中。这样，Flink 内部所有任务的状态，就恢复到了保存检查点的那一时刻

（3）重放数据

  从检查点恢复状态后如果直接继续处理数据，那么保存检查点之后、到发生故障这段时间内的数据就相当于丢掉了；这会造成计算结果的错误。为了不丢数据，应该从保存检查点后开始重新读取数据，这可以通过 Source 任务向外部数据源重新提交偏移量（offset）来实现。这样，整个系统的状态已经完全回退到了检查点保存完成的那一时刻

检查点配置

（1） 启用检查点

  默认情况下，Flink 程序是禁用检查点的。如果想要为 Flink 应用开启自动保存快照的功能，需要在代码中显式地调用执行环境的.enableCheckpointing()方法：

StreamExecutionEnvironment env =

StreamExecutionEnvironment.getExecutionEnvironment();

// 每隔 1 秒启动一次检查点保存

env.enableCheckpointing(1000);

（2）检查点存储（CheckpointStorage）

  检查点具体的持久化存储位置，取决于检查点存储（CheckpointStorage）的设置。默认情况下，检查点存储在JobManager 的堆（heap）内存中。而对于大状态的持久化保存，Flink也提供了在其他存储位置进行保存的接口，这就是 CheckpointStorage。具体 可以通过调用检查点配置的 .setCheckpointStorage() 来 配 置 ， 需 要 传 入 一个CheckpointStorage 的实现类。Flink 主要提供了两种 CheckpointStorage：作业管理器的堆内存（JobManagerCheckpointStorage）和文件系统（FileSystemCheckpointStorage）

// 配置存储检查点到JobManager 堆内存

env.getCheckpointConfig().setCheckpointStorage(new

JobManagerCheckpointStorage());

// 配置存储检查点到文件系统

env.getCheckpointConfig().setCheckpointStorage(new

FileSystemCheckpointStorage("hdfs://namenode:40010/flink/checkpoints"));

其他高级配置

（1）检查点模式（CheckpointingMode）

  设置检查点一致性的保证级别，有精确一次（exactly-once）和至少一次（at-least-once）两个选项。默认级别为 exactly-once，而对于大多数低延迟的流处理程序，at-least-once 就够用了，而且处理效率会更高

（2）超时时间（checkpointTimeout）

  用于指定检查点保存的超时时间，超时没完成就会被丢弃掉。传入一个长整型毫秒数作为参数，表示超时时间

（3）最小间隔时间（minPauseBetweenCheckpoints）

  用于指定在上一个检查点完成之后，检查点协调器（checkpoint coordinator）最快等多久可以发出保存下一个检查点的指令。这就意味着即使已经达到了周期触发的时间点，只要距离上一个检查点完成的间隔不够，就依然不能开启下一次检查点的保存。这就为正常处理数据留下了充足的间隙。当指定这个参数时，maxConcurrentCheckpoints 的值强制为 1

（4）最大并发检查点数量（maxConcurrentCheckpoints）

  用于指定运行中的检查点最多可以有多少个。由于每个任务的处理进度不同，完全可能出现后面的任务还没完成前一个检查点的保存、前面任务已经开始保存下一个检查点了。这个参数就是限制同时进行的最大数量。如果前面设置了 minPauseBetweenCheckpoints，则maxConcurrentCheckpoints 这个参数就不起作用了

（5）开启外部持久化存储（enableExternalizedCheckpoints）

  用于开启检查点的外部持久化，而且默认在作业失败的时候不会自动清理，如果想释放空间需要自己手工清理。里面传入的参数 ExternalizedCheckpointCleanup 指定了当作业取消的时候外部的检查点该如何清理。

DELETE_ON_CANCELLATION：在作业取消的时候会自动删除外部检查点，但是如果是作业失败退出，则会保留检查点。

RETAIN_ON_CANCELLATION：作业取消的时候也会保留外部检查点

（6）检查点异常时是否让整个任务失败（failOnCheckpointingErrors）

  用于指定在检查点发生异常的时候，是否应该让任务直接失败退出。默认为 true，如果设置为 false，则任务会丢弃掉检查点然后继续运行

（7）不对齐检查点（enableUnalignedCheckpoints）

  不再执行检查点的分界线对齐操作，启用之后可以大大减少产生背压时的检查点保存时间。这个设置要求检查点模式（CheckpointingMode）必须为 exctly-once，并且并发的检查点个数为 1

保存点（Savepoint）  

原理和算法与检查点完全相同，只是多了一些额外的元数据。事实上，保存点就是通过检查点的机制来创建流式作业状态的一致性镜像（consistent image）的。保存点中的状态快照，是以算子 ID 和状态名称组织起来的，相当于一个键值对。从保存点启动应用程序时，Flink 会将保存点的状态数据重新分配给相应的算子任务

（1）创建保存点

  要在命令行中为运行的作业创建一个保存点镜像，只需要执行：

bin/flink savepoint :jobId [:targetDirectory]

  对于保存点的默认路径，可以通过配置文件flink-conf.yaml 中的 state.savepoints.dir 项来设定：

state.savepoints.dir: hdfs:///flink/savepoints

  对于单独的作业，可以在程序代码中通过执行环境来设置：

env.setDefaultSavepointDir("hdfs:///flink/savepoints");

  由于创建保存点一般都是希望更改环境之后重启，所以创建之后往往紧接着就是停掉作业的操作。除了对运行的作业创建保存点，可以在停掉一个作业时直接创建保存点：

bin/flink stop --savepointPath [:targetDirectory] :jobId

（2）从保存点重启应用

  提交启动一个 Flink 作业，使用的命令是 flink run；现在要从保存点重启一个应用，其实本质是一样的：

bin/flink run -s :savepointPath [:runArgs]

实例：Flink CDC SQL Oracle To Kafka To ES_房石阳明i的博客-CSDN博客