flink checkpoint杂谈

       Flink的 Checkpoint 默认是关闭的，当Flink程序的checkpoint被激活时，状态会被持久化到checkpoint，以防止数据丢失和无缝恢复。状态在内部如何组织和它们如何以及在哪持久化，依赖于所选的状态后端。

        Flink默认状态是存储在 JM（JobManager）的 JVM内存中，当然也可以存储在远程文件系统如HDFS，只有将状态的快照持久化的保存起来，才能提供有利的保证，否则存储在 JM 的内存中，JM挂了之后状态就丢失了。

一.可选状态存储方式

Flink 自带了以下几种开箱即用的 state backend：

• MemoryStateBackend

• FsStateBackend

• RocksDBStateBackend

在没有配置的情况下，系统默认使用 MemoryStateBackend。

        尽管有checkpoint保证exactly-once，但对于实时性要求高的业务场景，每次重启所消耗的时间都可能会导致业务不可用。也许你也经常遇到这样的情况，checkpoint又失败了？连续失败？task manager 内存爆了？ 这些情况都很容易导致Flink任务down了，这时候需要思考下你所处的业务场景下，选用的Flink State Backends是否合理？

MemoryStateBackend

       Checkpoint 的存储，第一种是内存存储，即 MemoryStateBackend，构造方法是设置最大的StateSize，选择是否做异步快照，这种存储状态本身存储在 TaskManager 节点也就是执行节点内存中的，因为内存有容量限制，所以单个 State maxStateSize 默认5M，且需要注意 maxStateSize <= akka.framesize 默认 10 M。Checkpoint 存储在 JobManager 内存中，因此总大小不超过 JobManager 的内存。推荐使用的场景为：本地测试、几乎无状态的作业，比如 ETL、JobManager 不容易挂，或挂掉影响不大的情况。不推荐在生产场景使用。

FsStateBackend

       存储在文件系统上的 FsStateBackend ，构建方法是需要传一个文件路径和是否异步快照。State 依然在 TaskManager 内存中，但不会像 MemoryStateBackend 有 5 M 的设置上限，Checkpoint 存储在外部文件系统（本地或 HDFS），打破了总大小 Jobmanager 内存的限制。容量限制上，单 TaskManager 上 State 总量不超过它的内存，总大小不超过配置的文件系统容量。推荐使用的场景、常规使用状态的作业、例如分钟级窗口聚合或 join、需要开启HA的作业。

RocksDBStateBackend 

       存储为 RocksDBStateBackend ，RocksDB 是一个 key/value 的内存存储系统，和其他的 key/value 一样，先将状态放到内存中，如果内存快满时，则写入到磁盘中，但需要注意 RocksDB 不支持同步的 Checkpoint，构造方法中没有同步快照这个选项。不过 RocksDB 支持增量的 Checkpoint，也是目前唯一增量 Checkpoint 的 Backend，意味着并不需要把所有 sst 文件上传到 Checkpoint 目录，仅需要上传新生成的 sst 文件即可。它的 Checkpoint 存储在外部文件系统（本地或HDFS），其容量限制只要单个 TaskManager 上 State 总量不超过它的内存+磁盘，单 Key最大 2G，总大小不超过配置的文件系统容量即可。推荐使用的场景为：超大状态的作业，例如天级窗口聚合、需要开启 HA 的作业、最好是对状态读写性能要求不高的作业。

二.checkpoint的开启与配置

final StreamExecutionEnvironment env =StreamExecutionEnvironment.getExecutionEnvironment();
//启用检查点 每隔5000 ms进行启动一个检查点,则下一个检查点将在上一个检查点完成后5秒钟内启动
env.enableCheckpointing(5000);
//设置了 Exactly_Once 语义，表示需要 Barrier 对齐，这样可以保证消息不会丢失也不会重复。
env.getCheckpointConfig().setCheckpointingMode(CheckpointingMode.EXACTLY_ONCE);
//2 个 Checkpoint 之间最少是要等 500ms，也就是刚做完一个 Checkpoint。比如某个 Checkpoint 做了700ms，按照原则过 300ms 应该是做下一个 Checkpoint，因为设置了 1000ms 做一次 Checkpoint 的，但是中间的等待时间比较短，不足 500ms 了，需要多等 200ms，因此以这样的方式防止 Checkpoint 太过于频繁而导致业务处理的速度下降。
env.getCheckpointConfig().setMinPauseBetweenCheckpoints(500);
//表示做 Checkpoint 多久超时，如果 Checkpoint 在 1min 之内尚未完成，说明 Checkpoint 超时失败
env.getCheckpointConfig().setCheckpointTimeout(6000);
//表示同时有多少个 Checkpoint 在做快照，这个可以根据具体需求去做设置。
env.getCheckpointConfig().setMaxConcurrentCheckpoints(1);
//下 Cancel 时是否需要保留当前的 Checkpoint，默认 Checkpoint 会在整个作业 Cancel 时被删除。Checkpoint 是作业级别的保存点。    env.getCheckpointConfig().enableExternalizedCheckpoints(CheckpointConfig.ExternalizedCheckpointCleanup.DELETE_ON_CANCELLATION);

//设置存储位置覆盖默认方式
// env.setStateBackend(new FsStateBackend("hdfs://namenode:40010/flink/checkpoints"));
env.setStateBackend(...);