（7）Flink-CheckPoint

目录

1、checkpoint

2、StateBackend

3、Restart Strategies

3、SavePoint

---

1、checkpoint

默认情况下，checkpoint不会被保留，取消程序时即会删除它们，但是可以通过配置保留定期检查点。开启Checkpoint功能，有两种方式。其一是在conf/flink_conf.yaml中做系统设置；其二是针对任务再代码里灵活配置。推荐第二种方式，针对当前任务设置，设置代码如下所示：

//获取flink的运行环境
final StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();

//设置statebackend
env.setStateBackend(new MemoryStateBackend());

CheckpointConfig config = env.getCheckpointConfig();

// 任务流取消和故障时会保留Checkpoint数据，以便根据实际需要恢复到指定的Checkpoint
config.enableExternalizedCheckpoints(CheckpointConfig.ExternalizedCheckpointCleanup.RETAIN_ON_CANCELLATION);

// 设置checkpoint的周期, 每隔1000 ms进行启动一个检查点
config.setCheckpointInterval(1000);

// 设置模式为exactly-once
config.setCheckpointingMode(CheckpointingMode.EXACTLY_ONCE);

// 确保检查点之间有至少500 ms的间隔【checkpoint最小间隔】
config.setMinPauseBetweenCheckpoints(500);
// 检查点必须在一分钟内完成，或者被丢弃【checkpoint的超时时间】
config.setCheckpointTimeout(60000);
// 同一时间只允许进行一个检查点
config.setMaxConcurrentCheckpoints(1);

上面调用enableExternalizedCheckpoints设置为ExternalizedCheckpointCleanup.RETAIN_ON_CANCELLATION，表示一旦Flink处理程序被cancel后，会保留Checkpoint数据，以便根据实际需要恢复到指定的Checkpoint处理。
  ExternalizedCheckpointCleanup 可选项如下:

• ExternalizedCheckpointCleanup.RETAIN_ON_CANCELLATION： 取消作业时保留检查点。请注意，在这种情况下，您必须在取消后手动清理检查点状态。
• ExternalizedCheckpointCleanup.DELETE_ON_CANCELLATION： 取消作业时删除检查点。只有在作业失败时，检查点状态才可用。

默认情况下，如果设置了Checkpoint选项，则Flink只保留最近成功生成的1个Checkpoint，而当Flink程序失败时，可以从最近的这个Checkpoint来进行恢复。但是，如果希望保留多个Checkpoint，并能够根据实际需要选择其中一个进行恢复，这样会更加灵活，比如，发现最近4个小时数据记录处理有问题，希望将整个状态还原到4小时之前。
Flink可以支持保留多个Checkpoint，需要在Flink的配置文件conf/flink-conf.yaml中，添加如下配置，指定最多需要保存Checkpoint的个数：

    state.checkpoints.num-retained: 20

  Flink checkpoint目录分别对应的是 jobId，flink提供了在启动之时通过设置 -s 参数指定checkpoint目录, 让新的jobId 读取该checkpoint元文件信息和状态信息，从而达到指定时间节点启动job。

2、StateBackend

保存机制 StateBackend ，默认情况下，State 会保存在 TaskManager 的内存中，CheckPoint 会存储在 JobManager 的内存中。State 和 CheckPoint 的存储位置取决于 StateBackend 的配置。

Flink 一共提供了 3 中 StateBackend，包括

　　基于内存的 MemoryStateBackend

       基于文件系统的 FsStateBackend

       基于RockDB存储介质的 RocksDBState-Backend

1）MemoryStateBackend

基于内存的状态管理，具有非常快速和高效的特点，但也具有非常多的限制。最主要的就是内存的容量限制，

一旦存储的状态数据过多就会导致系统内存溢出等问题，从而影响整个应用的正常运行。同时如果机器出现问题，

整个主机内存中的状态数据都会丢失，进而无法恢复任务中的状态数据。因此从数据安全的角度建议用户尽可能地避免

在生产环境中使用 MemoryStateBackend

streamEnv.setStateBackend(new MemoryStateBackend(10*1024*1024))

2）FsStateBackend

和MemoryStateBackend有所不同，FsStateBackend是基于文件系统的一种状态管理器，这里的文件系统可以是本地文件系统，

也可以是HDFS分布式文件 系统。FsStateBackend更适合任务状态非常大的情况，例如：应用中含有时间范围非常长的窗口计算，

或 Key/Value State 状态数据量非常大的场景。

streamEnv.setStateBackend(new FsStateBackend("hdfs://hadoop101:9000/checkpoint/cp1"))

3）RocksDBStatusBackend

RocksDBStatusBackend是Flink中内置的第三方状态管理器，和前面的状态管理器不同，RocksDBStateBackend 需要单独引入

相关的依赖包到工程中。

<dependency>
　　<groupId>org.apache.flink</groupId>
　　<artifactId>flink-statebackend-rocksdb_2.11</artifactId>
　　<version>1.9.1</version>
</dependency>

 

RocksDBStateBackend 采用异步的方式进行状态数据的 Snapshot，任务中的状态数据首先被写入本地 RockDB 中，这样在

RockDB 仅会存储正在计算的热数据，而需要进行 CheckPoint 的时候，会把本地的数据直接复制到远端的 FileSystem 中。

　　与 FsStateBackend 相比，RocksDBStateBackend 在性能上要比 FsStateBackend 高一些，主要是因为借助于 RocksDB 在

本地存储了最新热数据，然后通过异步的方式再同步到文件系统中，但 RocksDBStateBackend 和 MemoryStateBackend 相比性能

就会较弱一些。RocksDB 克服了 State 受内存限制的缺点，同时又能够持久化到远端文件系统中，推荐在生产中使用。

streamEnv.setStateBackend(new RocksDBStateBackend("hdfs://hadoop101:9000/checkpoint/cp2"))

---

前面的几个代码都是单 job 配置状态后端，也可以全局配置状态后端，需要修改 flink-conf.yaml配置文件：

state.backend:filesystem

 

其中：

　　filesystem 表示使用 FsStateBackend

　　jobmanager 表示使用 MemoryStateBackend

　　rocksdb 表示使用 RocksDBStateBackend

state.checkpoint.dir:hdfs://hadoop101:9000/checkpoints

默认情况下，如果设置了 Checkpoint 选项，则 Flink 只保留最近成功生成的 1 个 Checkpoint，而当 Flink 程序失败时，可以通过最近的 CheckPoint 来进行恢复。但是希望保留多个 CheclPoint，并能够根据实际需要选择其中一个进行恢复，就会更加灵活。添加如下配置，指定最多可以保存的 CheckPoint 的个数.

state.checkpoints.num-retained: 2

3、Restart Strategies

重启策略：

 Flink 的配置文件 flink-conf.yaml 指定。配置参数 restart-strategy ，也可以在应用代码中动态指定，会覆盖全局配置

常用的重启策略

1 固定间隔 (Fixed delay)

2 失败率 (Failure rate)

3 无重启 (No restart)

固定间隔 (fixed-delay) 策略

如果没有启用 checkpointing，则使用无重启 (no restart) 策略。

如果启用了 checkpointing，但没有配置重启策略，则使用固定间隔 (fixed-delay) 策略，其中 Integer.MAX_VALUE 参数是尝试重启次数。

 一：全局配置 flink-conf.yaml

restart-strategy: fixed-delay

restart-strategy.fixed-delay.attempts: 3

restart-strategy.fixed-delay.delay: 10 s

二：应用代码设置

env.setRestartStrategy(RestartStrategies.fixedDelayRestart(

3, // 尝试重启的次数  

Time.of(10, TimeUnit.SECONDS) //间隔));

重启策略之失败率 (Failure rate)

第一种：全局配置 flink-conf.yaml

restart-strategy: failure-rate

restart-strategy.failure-rate.max-failures-per-interval: 3

restart-strategy.failure-rate.failure-rate-interval: 5 min

restart-strategy.failure-rate.delay: 10 s

第二种：应用代码设置

env.setRestartStrategy(RestartStrategies.failureRateRestart(

  3, // 一个时间段内的最大失败次数

  Time.of(5, TimeUnit.MINUTES), // 衡量失败次数的是时间段

  Time.of(10, TimeUnit.SECONDS) // 间隔

));

重启策略之无重启 (No restart)

第一种：全局配置 flink-conf.yaml

restart-strategy: none

第二种：应用代码设置

env.setRestartStrategy(RestartStrategies.noRestart())

3、SavePoint

一版在升级的情况下使用。为了能够在作业的不同版本之间以及Flink的不通版本之间顺利升级，推荐使用。