flink实现状态一致性

状态一致性分类：
At-Most-Once（最多一次）
当任务故障时，最简单的做法是什么都不干，即不恢复丢失的状态，也不重播丢失的数据。
At-most-once的语义是最多处理一次的事件
At-Least-Once(至少一次)
在大多数的真实应用场景中，我们希望不丢失事件。这种类型的保障成为at-least-once，意思就是所有的事件都得到处理，而且有一些事件还可能被处理多次
ExactLy-Once(精确一次)
恰好处理一次是最严格的保证，也是最难实现的。恰好处理一次语义不仅仅意味着没有事件丢失，还意味着每一个数据，内部状态仅仅更新一次

flink的内部的精确一次性实现：
flink用到的是轻量级的快照机制–checkpoint检查点来保证精确一致性。当发生故障的时候，从上一次的checkpoint中恢复出来，重新执行。
有状态流应用的一致检查点，其实就是：所有任务的状态，在某个时间点的一份拷贝（快照）。而这个时间点，应该是所有任务都恰好处理完一个相同的输入数据的时候。

端到端状态的一致性：
端到端的一致性保证，意味着结果的正确性贯穿了整个流处理应用的始终；每一个组件都保证它自己的一致性。比如：kafka的一致性和FLink内部的一致性
端到端一致性：
内部保证------checkpoint机制保证
source端保证------可以重新设置数据的读取位置（比如重新设置kafka的偏移量）
sink端保证-------从故障恢复时，数据不会写入外部系统
sink有两种方法：幂等写入和事务写入
事务写入实现的方式：
（1）预写日志 （2）两阶段提交
预写日志（WAL）：把结果数据先当成状态保存，然后在收到checkpoint完成的通知时，一次性写入sink系统。
优点：
简单易实现，由于数据提前在状态后端中做了缓存，所以无论什么sink系统，都能用这种方式一批搞定
缺点：当收到checkpoint完成的通知后，向外部系统写数据的时候，出现了故障。
DataStream Api提供了一个模板类：GenericWriteAheadSink，来实现这种事务性sink。

两阶段提交（2pc:真正能够实现精确一次）
对于每一个checkpoint和sink任务启动一个事务，并将接下来所有接收的数据添加到事务中，然后将这些数据写到外部sink系统中，但是不提交他们–这只是“预提交”。当它收到checkpoint完成通知的时候，它才正式提交事务，实现结果的真正写入。
Flink提供了TwoPhaseCommitSinkFunction接口
2pc方式对外部sink系统的要求：
这种方式真正实现了精确一次，它需要一个支持事务支持的外部sink系统。
在两个checkpoint的期间，必须能够开启一个事务并接收数据写入
在收到checkpoint完成的通知之前，事务必须是“等待提交”的状态。在故障恢复的情况下，这可能需要一些时间。如果这时候sink系统关闭事务（例如超时了），那么未提交的数据将会丢失。
sink任务必须能够在进程失败后恢复事务
提交事务必须是幂等操作。