Flink状态一致性

如图：奇数和偶数分流分别计算

概念

• 计算结果要保证准确。
• 一条数据不应该丢失，也不应该重复计算。
• 遇到故障时可以恢复状态，恢复以后的重新计算结果应该也是完全正确的。

状态一致性分类（级别）

• AT-MOST-ONCE（最多一次）
  当任务故障时，最简单的做法是什么都不干，既不恢复丢失的状态，也不重播丢失的数据。即最多处理一次事件。

• AT-LEAST-ONCE（至少一次）
  （不能保证数据不被重复处理）
  在大多数真实应用场景，我们希望不丢事件。但是有些事件还可能被处理多次。

• EXACTLY-ONCE（精确一次）
  恰好处理一次是最严格的保证，恰好处理一次语义不仅仅意味着没有事件丢失，还意味着针对每个数据只处理一次
  （checkpoint存盘方式）

一致性检查点（checkpoints）

• Flink使用了一种轻量级快照机制--检查点checkpoint来保证exactly-once语义。
• 有状态流应用的一致性检查点实质时所有任务的状态在某个时间点的一份拷贝（一份快照）。而这个时间点应该是所有任务恰好处理完一个相同的输入数据的时间点。

问题：2+4=6，1+3+5=9，当source为6时，内部6+6=12，如果加上sink，在此时出现故障，就需要恢复到source为5的时候的状态，而内部Strorage已经变成了“6，12，9”的checkpoint，所以引出端到端的状态一致性

端到端（end-to-end）状态一致性

• 目前我们看到的一致性保证都是由流处理器实现的，也就是说都是在 Flink 流处理器内部保证的；而在真实应用中，流处理应用除了流处理器以外还包含了数据源（例如 Kafka）和输出到持久化系统
• 端到端的一致性保证，意味着结果的正确性贯穿了整个流处理应用的始终；每一个组件都保证了它自己的一致性
• 整个端到端的一致性级别取决于所有组件中一致性最弱的组件（状态一致性级别）

端到端exactly-once保证

• 内部保证--checkpoint
• source端--可重设数据的读取位置
• sink端--从故障恢复时，数据不会重复写入外部系统
  幂等写入
  事务写入

幂等写入

就是一个操作，可以重复执行很多次，但只导致一次结果更改，也就是说，后面再重复执行就不起作用。

reids写入时，

redis写入如果挂了，会重放一遍上一个状态

---

事务写入

• 一致性： 所有操作必须完成

• 原子性：一个事务中一系列操作要么全部成功，要么全部回滚

• 构建的事务对应着checkpoint，等到checkpoint真正完成的时候，才把所有对应的结果写入sink系统中

• 实现方式：

预写日志（Write-Ahead-Log)
1）把结果数据先当成状态保存，然后收到checkpoint完成的通知时，一次性写入sink系统。

2）由于数据提前在状态后端(state backend)中做了缓存，所以无论什么 sink 系统，都能用这种方式一批搞定
3）DataStream API提供了一个模板类：GenericWriteAheadSink来实现这种事务性sink

预写日志方式会出现的问题：

1）日志丢了，导致写入外部sink系统不成功
2）在data sink中要保证Exactly-Once语义，它必须将所有的写入数据通过一个事务提交。在两个checkpoint之间，一个提交绑定了所有要写入的数据。当出错的时候，写入的数据可以被回滚。然而在分布式系统中，通常拥有多个并行执行的写入任务，简单的提交和回滚是效率低下的。为了保证一致性，所有的组件必须先达成一致，才能进行提交或者回滚。Flink使用了两阶段提交协议以及预提交阶段来解决这个问题。（实际是保证了at-least-once级别而不是Exactly-Once）

两阶段提交two-parse commit
1）对于每个checkpoint，sink任务会启动一个事务，并将接下来所有接收的数据添加到事务里。
2）将这些数据写入外部sink系统，但是不提交它们，只是“预提交”。
3）当它收到checkpoint完成的通知时，才正式提交事务，实现结果的真正写入。
4）这种方式真正实现了exactly-once。
5）这种方式真正实现了exactly-once，它需要一个提供事务支持的外部sink系统，Flink提供了TwoPhaseCommitSinkFunction接口。

TwoPhaseCommitSink对外部sink系统的要求

• 外部 sink 系统必须提供事务支持，或者 sink 任务必须能够模拟外部系统上的事务

• 在 checkpoint 的间隔期间里，必须能够开启一个事务并接受数据写入

• 在收到 checkpoint 完成的通知之前，事务必须是“等待提交”的状态。在故障恢复的情况下，这可能需要一些时间。如果这个时候sink系统关闭事务（例如超时了），那么未提交的数据就会丢失

• sink 任务必须能够在进程失败后恢复事务

• 提交事务必须是幂等操作

  
  
  

  幂等会出现暂时不一致是指一批数据回滚后，在发生故障前这批数据已经有写入sink的了，回滚会重新重播这部分数据，但是它是幂等操作，所以还是保证了Exactly-once。