Flink状态编程和容错机制

算子状态:
算子状态（None key状态）的作用范围限定为算子任务。这意味着由同一并行任务所处理的所有数据都可以访问到相同的状态，状态对于同一任务而言是共享的。算子状态不能由相同或不同算子的另一个任务访问。

键控状态:
键控状态是根据输入数据流中定义的键（key）来维护和访问的。Flink 为每个键值维护
一个状态实例，并将具有相同键的所有数据，都分区到同一个算子任务中，这个任务会维护
和处理这个 key 对应的状态。当任务处理一条数据时，它会自动将状态的访问范围限定为当前数据的 key。因此，具有相同 key 的所有数据都会访问相同的状态。Keyed State 很类似于一个分布式的 key-value map 数据结构，只能用于 KeyedStream（keyBy 算子处理之后）。

状态后端（StateBackends）
每传入一条数据，有状态的算子任务都会读取和更新状态
由于有效的访问状态对于处理数据的低延迟至关重要，因此每个并行的任务都会在本地维护其状态，以确保快速的访问状态。
状态的存储，访问以及维护，由一个可插入的组件决定，这个组件就叫状态后端StateBackend
状态后端主要负责两件事，本地状态管理，以及检查点checkpoint状态写入远程存储

可以自定义选状态后端
MemoryStateBackend
内存状态后端，会将键控状态作为内存中的对象进行管理，本地状态将他们存储在TaskManager的JVM堆上，而checkpoint存储在jobmanager的内存中。
特点：快速 低延迟 不稳定
FsStateBackend
将checkpoint存储到远程持久化文件系统上（FileSystem），而对于本地的状态跟menoryStateBackend一样，也会存TaskManager的JVM堆上。
同时拥有本地级的访问速度和更好的容错性能，唯一缺点就是保存到checkpoint端的时候效率会低，故障恢复的是会从checkpoint端读取的时候效率会低。
RocksDBStateBackend
将所有的状态序列化后，存入本地的RocksDB中存储
状态一致性:
在流处理中，一致性可以分为 3 个级别：
at-most-once: 最多处理一次（处理一次或者不处理）这其实是没有正确性保障的委婉说法——故障发生之后，计数结果可能丢失。当任务故障时，最简单的做法什么都不干，既不恢复丢失状态，也不重播丢失数据，最多处理一次事件。效率高，牺牲容错性保障高效率。

at-least-once: 最少计算一次，这表示计数结果可能大于正确值，但绝不会小于正确值。也就是说，计数程序在发生故障后可能多算，但是绝不会少算。在多数的正式场景，我们希望不丢失事件，这种类型的保障称为at-least-once，意思所有数据都得到了处理，而一些事件还可能处理多次。数据会被保存到本地wal，结果确认机制ack。

exactly-once: 精确消费一次，这指的是系统保证在发生故障后得到的计数结果与正确值一致。恰好处理一次是最严格的保障，也是最难的。恰好精确消费一次语义不仅仅意味着没有丢失事件，还意味着每一个事件，内部状态仅仅更新一次。不重复不丢失。

端到端状态一致性:
幂等写入:
所谓幂等操作，是说一个操作，可以重复执行很多次，但只导致一次结果更改，也就是说，后面再重复执行就不起作用了。最典型的就是查询、通知。
事务写入
WAL预写日志:把结果先作为状态保存(预提交状态),再收到所有checkpoint完成的同时,一次性写入
两阶段提交
在checkpoint完成通知之前，事务必须是“等待提交”的状态,全部处理完得到通知后,一次性写入到sink系统中

检查点(checkpoint):
Flink 具体如何保证 exactly-once 呢? 它使用一种被称为"检查点"（checkpoint）的特性，在出现故障时将系统重置回正确状态。
Checkpoint实际是两个值：数据的位置，状态的值。

• Flink 将输入流倒回到上一个检查点屏障的位置，同时恢复 map 算子的状态值。然后，Flink从此处开始重新处理。这样做保证了在记录被处理之后，map 算子的状态值与没有发生故障时的一致。
• Flink 检查点算法的正式名称是异步分界线快照(asynchronous barrier snapshotting)。该算法大致基于
  Chandy-Lamport 分布式快照算法。

检查点是 Flink 最有价值的创新之一，因为它使 Flink 可以保证 exactly-once，并且不需要牺牲性能。