1. State Backend

Flink管理的state存储在state backend里。一种是RocksDB, 一种是JVM heap. 其特点如下：

2. Checkpoint Storage

Flink会定期将各个operator的state快照copy到更持久的存储中，比如分布式文件系统，系统失败后从恢复一个完整的state并继续运行。快照的存储位置是由jobs checkpoint storage指定的，也有两种实现：

3. State Snapshots

先看几个定义：

1. snapshot: Flink job state的一个镜像，包含指向数据源位置的指针以及所有operator job的state的备份
2. checkpoint: Flink自动触发的用于错误恢复的snapshot，checkpoint可以是增量生成的，为快速存储做了优化。默认Flink只会在job运行时保留最近的几个checkpoint, 并在job取消后删除checkpoint
3. Externalized checkpoint: 通过配置让Flink保留并供用户操作的checkpoint
4. Savepoint: 由用户手动触发或API调用触发的snapshot, 比如为了有状态的升级，重新部署，扩展规模等，savepoint为运维灵活性做了优化

Snapshotting是怎么工作的：
Flink使用了异步屏障快照Chandy-Lamport algorithm
当checkpoint coordinator(job manager的一部分)指示task manager开始一个checkpoint后，task manager记录下他们的偏移量，并将checkpoint 屏障插入到他的stream中，这些屏障就能标记出哪些event在当前checkpoint中，哪些不在。checkpoint n会包含所有在他之前到达的event. 每一个operator都会收到一个屏障从而去记录自己的状态。对于哪些有两个input stream的operator会把两个stream的消费状态都记录下来。Flink的state backends采用copy-on-write的机制，保证当旧版本的状态在异步生成快照时，流处理能够不受影响地继续进行。只有当快照被持久化存储以后，旧版本的状态才会被垃圾回收。
精确一次的保证
Flink支持三种处理原则：最多一次，最少一次和精确一次。选择精确一次时Flink会回退到source stream的与checkpoint一致的点重新开始运行，所以精确一次并不是说一个event只被处理一次，而是一个event只会影响state一次。
端到端的精确一次
要保证source到sink的精确一次要求source必须是可回退重播的，且sink必须是支持事务的。