说明
当使用 checkpoint 时，状态(state)会被持久化，以防止数据的丢失并确保发生故障时能够完全恢复。
状态是通过什么方式持久化，取决于使用的 状态后端
状态后端 主要负责两件事：
- Local State Management(本地状态管理)
- Remote State Checkpointing（远程状态备份）
可用的状态后端
MemoryStateBackend，默认
FsStateBackend
RocksDBStateBackend
注意：如果什么都不配置，系统默认的是MemoryStateBackend
MemoryStateBackend
直接将State对象存储到TaskManager的JVM堆上
缺点
每一个状态的大小限制为 5 MB
聚合的状态必须能够在JobManager内存中存放下，即：状态的总大小不能超过 JobManager 的内存
生产环境中几乎不用
应用场景
本地测试、几乎无状态的作业，比如 ETL、JobManager 不容易挂，或挂掉影响不大的情况。
不推荐在生产场景使用。
FsStateBackend（推荐）
在 checkpoint 时，将状态快照写入配置的文件系统中，如：HDFS
hdfs路径:
hdfs://namenode:8020/flink/checkpoint本地文件系统路径：
file:///D:/flink/checkpoints
缺点
状态先会存在 TaskManager 中，所以状态的大小不能超过 TaskManager 的内存，以免发生OOM。
应用场景
- 处理大状态，长窗口，或大键值状态的有状态处理任务， 例如分钟级窗口聚合或 join。
- 适合用于高可用方案（需要开启HA的作业）。
- 可以在生产环境中使用
RocksDBStateBackend（推荐）
主要是文件系统，如 HDFS
- 状态存储在
RocksDB数据库 - 在
checkpoint时，整个RocksDB数据库会被存储到配置的文件系统中，如：HDFS
RocksDB
RocksDB 是一种 嵌入式 ，key/value 数据库。先将状态放到内存中，如果内存快满时，则写入到磁盘中
注意：
- RocksDB不支持同步的 Checkpoint
- RocksDB支持增量的 Checkpoint
缺点
RocksDB支持的单key和单value的大小最大为每个 2^31 字节，即：2G。
对于使用具有合并操作的状态的应用程序，例如 ListState，随着时间可能会累积到超过 2^31 字节大小，这将会导致在接下来的查询中失败。
性能差一些，状态会存储在硬盘上
应用场景
- 最适合用于处理超大状态，长窗口，或大键值状态的有状态处理任务，例如天级别窗口聚合。
- 非常适合用于高可用方案。
- 最好是对状态读写性能要求不高的作业
依赖
<dependency>
<groupId>org.apache.flink</groupId>
<artifactId>flink-statebackend-rocksdb_2.12</artifactId>
<version>1.12.0</version>
</dependency>
选择
RocksDBStateBackend直接将State存储到RocksDB数据库中，所以 不受JobManager的内存限制，但会有 读写延迟
同时 RocksDBStateBackend 支持增量备份，如果不是对延迟有极高的要求，RocksDBStateBackend是更好的选择