状态持久化
检查点的保存离不开 JobManager 和 TaskManager，以及外部存储系统的协调。在应用进行检查点保存时，首先会由 JobManager 向所有 TaskManager 发出触发检查点的命令；TaskManger 收到之后，将当前任务的所有状态进行快照保存，持久化到远程的存储介质中；完成之后向JobManager 返回确认信息。这个过程是分布式的，当 JobManger 收到所有TaskManager 的返回信息后，就会确认当前检查点成功保存，而这一切工作的协调，就需要一个“专职人员”状态后端来完成。
检查点（Checkpoint）
有状态流应用中的检查点（checkpoint），其实就是所有任务的状态在某个时间点的一个快 照（一份拷贝）。简单来讲，就是一次“存盘”，让我们之前处理数据的进度不要丢掉。在一个 流应用程序运行时，Flink 会定期保存检查点，在检查点中会记录每个算子的 id 和状态；如果 发生故障，Flink 就会用最近一次成功保存的检查点来恢复应用的状态，重新启动处理流程， 就如同“读档”一样。
默认情况下，检查点是被禁用的，需要在代码中手动开启。
env.enableCheckpointing(1000);//单位为毫秒保存点（savepoint）
存点在原理和形式上跟检查点完全一样，也是状态持久化保存的一个快照；区别在于，保存点是自定义的镜像保存，所以不会由 Flink 自动创建，而需要用户手动触发。这在有计划地停止、重启应用时非常有用。
状态后端
在 Flink 中，状态的存储、访问以及维护，都是由一个可插拔的组件决定的，这个组件就 叫作状态后端（state backend）。状态后端主要负责两件事：一是本地的状态管理，二是将检查点（checkpoint）写入远程的持久化存储。
状态后端是一个“开箱即用”的组件，可以在不改变应用程序逻辑的情况下独立配置。 Flink 中提供了两类不同的状态后端，一种是“哈希表状态后端”（HashMapStateBackend），另 一种是“内嵌 RocksDB 状态后端”（EmbeddedRocksDBStateBackend）。如果没有特别配置， 系统默认的状态后端是 HashMapStateBackend。
哈希表状态后端（HashMapStateBackend）
这种方式就是我们之前所说的，把状态存放在内存里。具体实现上，哈希表状态后端在内
部会直接把状态当作对象（objects），保存在 Taskmanager 的 JVM 堆（heap）上。普通的状态， 以及窗口中收集的数据和触发器（triggers），都会以键值对（key-value）的形式存储起来，所 以底层是一个哈希表（HashMap），这种状态后端也因此得名。
HashMapStateBackend 是将本地状态全部放入内存的，这样可以获得最快的读写速度，使
计算性能达到最佳，代价则是内存的占用。
内嵌 RocksDB 状态后端（EmbeddedRocksDBStateBackend）
RocksDB 是一种内嵌的 key-value 存储介质，可以把数据持久化到本地硬盘。配置 EmbeddedRocksDBStateBackend 后，会将处理中的数据全部放入 RocksDB 数据库中RocksDB
默认存储在 TaskManager 的本地数据目录里。数据被存储为序列化的字节数组（Byte Arrays），读写操作需要序列化/反序列化，因此状态的访问性能要差一些。
由于它会把状态数据落盘，而且支持增量化的检查点，所以在状态非常大、窗口非常长、
键/值状态很大的应用场景中是一个好选择，同样对所有高可用性设置有效。
状态后端的配置
- flink-conf.yaml 中，可以使用 state.backend 来配置默认状态后端。
- 每个作业独立的状态后端，可以在代码中，基于作业的执行环境直接设置。
