什么是状态一致性
1. 有状态的流处理，内部每个算子任务都可以有自己的状态。
2. 对于流处理内部来说，所谓的状态一致性，其实就是我们所说的计算结果要保持准确。
3. 一条数据不应该丢失，也不应该重复计算。
4. 在遇到故障时可以恢复状态，恢复以后的重新计算，结果应该也是完全正确的。
状态一致性分类
1. 最多一次 at most once
2. 至少一次 at least once
3. 精确一次 exactly once
一致性检查点
1. flink使用了一种轻量级快照机制--检查点（checkpoint）来保证exactly once语义。
2. 有状态流应用的一致检查点，其实就是：所有任务的状态，在某个时间点的一个拷贝（一份快照）。而这个时间点，应该是所有任务都恰好处理完一个相同的输入数据的时候。
3. 应用状态的一致检查点，是flink故障恢复机制的核心。
端到端（end-to-end）状态一致性
1. 目前我们看到的一致性保证都是由流处理器实现的，也就是说都是在Flink流处理器内部保证的；而在真实应用中，流处理应用除了流处理器以外，还包含了数据源（如Kafka）和输出到持久化系统。
2. 端到端的一致性保证，意味着结果的正确性贯穿了整个流处理应用的始终。每一个组件都保证了它自己的一致性。
3. 整个端到端一致性级别取决于所有组件中一致性最弱的组件。
4. 内部保证：checkpoint
5. source端：可重设数据的读取位置
6. sink端：从故障恢复时，数据不会重复写入外部系统。
幂等写入：所谓幂等写入（idempotent writes），是说一个操作，可以重复执行很多次，但只导致一次结果更改，也就是说，后面再重复执行就不起作用了。
事务写入：（transactional writes）,事务，应用程序中一系列严密的操作，所有操作必须成功完成，否则在每个操作中所作的所有更改都会被撤销。
具有原子性，一个事务中的一系列操作要么都成功，要么一个不执行。
实现思想，构建的事务对应着checkpoint，等到checkpoint真正完成的时候，才把所有对应的结果写入到sink系统中。
实现方式：
预写日志：把结果数据先当成状态保存，然后在收到完成的通知时，一次性写入到sink系统。
优点，简单易实现，由于数据提前在状态后端做了缓存，所以无论什么sink系统，都能用这种方式一批搞定。
datastream api提供了一个模板类：GenericWriteAheadSink,来实现这种事务性sink。
两阶段提交：对于每个checkpoint，sink任务会启动一个事务，并将接下来所有接收的数据添加到事务里。
然后将这些数据写入外部sink系统，但不提它们，这时只是预提交。
当它收到checkpoint完成的通知时，它才正式提交事务，实现结果的真正写入。
这种方式真正实现了exactly once，它需要一个提供事务支持的外部sink系统。flink提供了TwoPhaseCommitSinkFunction接口。
