1.前言
在Flink中，函数和操作符都可以是有状态的。在处理每个消息或者元素时，有状态的函数都会储存信息，使得状态成为精密操作中关键的组成部分。
为了使状态能够容错，Flink会checkpoints状态。checkpoints机制使得Flink可以恢复状态和位置，以至于流计算的应用可以提供无故障执行的语义。
2.前提
Flink的checkpointing机制对流和状态的可靠存储有如下两点要求：
- 持久化的数据源能够从某个时间进行消息回放。举个例子，对于消息队列而言，有Kafka，RabbitMQ，Kinesis，PubSub，对文件系统而言，有Hdfs，S3，Ceph等。
- 状态的持久化存储。一般会保存在分布式文件系统中，比如HDFS和S3。
3.启用和配置Checkpointing
Flink默认不启用Checkpointing。如果要启用，可以在StreamExecutionEnvironment上调用enableCheckpointing(n)，其中n是以毫秒为单位的checkpoint间隔。
还有其他一些参数：
- exactly-once vs at-least-once：在enableCheckpointing(n)中可以传递模式，对于大多数应用可能exactly-once适合，但对于延迟要求在毫秒级别的，或许也可以设置为at-least-once。
- checkpoint timeout：如果超过这个时间checkpoint还没结束，就会被认为是失败的。
- minimum time between checkpoints：规定在两次checkpoints之间的最小时间是为了流应用可以在此期间有明显的处理进度。比如这个值被设置为5秒，则在上一次checkpoint结束5秒之内不会有新的checkpoint被触发。这也通常意味着checkpoint interval的值会比这个值要大。为什么要设置这个值？因为checkpiont interval有时候会不可靠，比如当文件系统反应比较慢的时候，checkpiont花费的时间可能就比预想的要多，这样仅仅只有checkpoint interval的话就会重叠。记住，设置minimum time between checkpoints也要求checkpoints的并发度是1。
- number of concurrent checkpoints：默认，Flink在有一个checkpoint在执行的时候不会触发另一次checkpoint。但如果非要做，比如对于处理有延迟的流水线操作而言，又希望能够高频的进行checkpoint，则可以更改这个值。如果设置了minimum time between checkpoints，就不要设置这个值。
- externalized checkpoints：externalized checkpoints将元数据也会写入持久化存储，并且在作业失败的时候不会自动清除数据。这样，你就获得了作业失败之后的一个恢复点。
- fail/continue task on checkpoint errors：这个值规定当某次checkpoint执行失败的时候，task是否要被认为是执行失败。Flink默认checkpoint失败则task处理失败。但是你可以改，如果改了，那么checkpoint失败的时候，task还会继续运行，只是会告诉checkpoint协调器这次checkpoint失败了。
StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment(); // start a checkpoint every 1000 ms env.enableCheckpointing(1000); // advanced options: // set mode to exactly-once (this is the default) env.getCheckpointConfig().setCheckpointingMode(CheckpointingMode.EXACTLY_ONCE); // make sure 500 ms of progress happen between checkpoints env.getCheckpointConfig().setMinPauseBetweenCheckpoints(500); // checkpoints have to complete within one minute, or are discarded env.getCheckpointConfig().setCheckpointTimeout(60000); // allow only one checkpoint to be in progress at the same time env.getCheckpointConfig().setMaxConcurrentCheckpoints(1); // enable externalized checkpoints which are retained after job cancellation env.getCheckpointConfig().enableExternalizedCheckpoints(ExternalizedCheckpointCleanup.RETAIN_ON_CANCELLATION);
相关的配置选项
| Key | Default | Description |
|---|---|---|
state.backend |
(none) | The state backend to be used to store and checkpoint state. |
state.backend.async |
true | Option whether the state backend should use an asynchronous snapshot method where possible and configurable. Some state backends may not support asynchronous snapshots, or only support asynchronous snapshots, and ignore this option. |
state.backend.fs.memory-threshold |
1024 | The minimum size of state data files. All state chunks smaller than that are stored inline in the root checkpoint metadata file. |
state.backend.incremental |
false | Option whether the state backend should create incremental checkpoints, if possible. For an incremental checkpoint, only a diff from the previous checkpoint is stored, rather than the complete checkpoint state. Some state backends may not support incremental checkpoints and ignore this option. |
state.backend.local-recovery |
false | |
state.backend.rocksdb.localdir |
(none) | The local directory (on the TaskManager) where RocksDB puts its files. |
state.checkpoints.dir |
(none) | The default directory used for storing the data files and meta data of checkpoints in a Flink supported filesystem. The storage path must be accessible from all participating processes/nodes(i.e. all TaskManagers and JobManagers). |
state.checkpoints.num-retained |
1 | The maximum number of completed checkpoints to retain. |
state.savepoints.dir |
(none) | The default directory for savepoints. Used by the state backends that write savepoints to file systems (MemoryStateBackend, FsStateBackend, RocksDBStateBackend). |
taskmanager.state.local.root-dirs |
(none) |
4.选择存储策略
Flink的checkpointing机制会存储状态的一致性快照，配置了不同的状态存储策略，checkpoints就会保存在不同的地方，比如JM的内存，文件系统还是数据库。
默认，状态会保存在TM的内存中，checkpoints会保存在JM的内存中。但是为了保存特别大的状态，Flink也支持将状态保存和checkpointing到其他的地方。
5.迭代作业中的状态保存点
Flink目前只对没有迭代的作业提供处理保证。在迭代作业中进行checkpointing会导致异常发生，如果用户强制要在迭代应用中启用checkpoint，则需要设置env.enableCheckpointing(interval, force = true)，但这也不能保证处在循环边界上的数据和状态不会丢失。
6.重启策略
Flink支持很多重启策略，比如Fixed Delay Restart Strategy，Failure Rate Restart Strategy，No Restart Strategy，Fallback Restart Strategy，容后再叙。
7.checkpoints
与savepoints的区别
- 数据结构，savepoints有自己的数据结构，checkpoints的数据结构和状态的存储结构相同。
- 触发方式，savepoints只能对状态进行全量快照保存，checkpoints可以对状态的快照进行增量快照处理。
- 应用并发，savepoints支持应用并发的调整，checkpoints不支持调整。