Flink流计算编程--状态与检查点

1、Exactly_once简介

Exactly_once语义是Flink的特性之一，那么Flink到底提供了什么层次的Excactly_once？有人说是是每个算子保证只处理一次，有人说是每条数据保证只处理一次。其实理解这个语义并不难，直接在官方文档中就可以看出：

从图中可以看出：Exactly_once是为有状态的计算准备的！

换句话说，没有状态的算子操作（operator），Flink无法也无需保证其只被处理Exactly_once!为什么无需呢？因为即使失败的情况下，无状态的operator（map、filter等）只需要数据重新计算一遍即可。例如:

dataStream.filter(_.isInNYC)

当机器、节点等失败时，只需从最近的一份快照开始，利用可重发的数据源重发一次数据即可，当数据经过filter算子时，全部重新算一次即可，根本不需要区分哪个数据被计算过，哪个数据没有被计算过，因为没有状态的算子只有输入和输出，没有状态可以保存。

2、Flink的恢复机制

Flink的失败恢复依赖于“检查点机制+可部分重发的数据源”。

2.1、检查点机制：检查点定期触发，产生快照，快照中记录了（1）当前检查点开始时数据源（例如Kafka）中消息的offset，（2）记录了所有有状态的operator当前的状态信息（例如sum中的数值）。

2.2、可部分重发的数据源：Flink选择最近完成的检查点K。然后系统重放整个分布式的数据流，然后给予每个operator他们在检查点k快照中的状态。数据源被设置为从位置Sk开始重新读取流。例如在Apache Kafka中，那意味着告诉消费者从偏移量Sk开始重新消费。

容错特性：

3、检查点与保存点

3.1、检查点

Flink的检查点机制实现了标准的Chandy-Lamport算法，并用来实现分布式快照。在分布式快照当中，有一个核心的元素：Barrier。

屏障作为数据流的一部分随着记录被注入到数据流中。屏障永远不会赶超通常的流记录，它会严格遵循顺序。屏障将数据流中的记录隔离成一系列的记录集合，并将一些集合中的数据加入到当前的快照中，而另一些数据加入到下一个快照中。每一个屏障携带着快照的ID，快照记录着ID并且将其放在快照数据的前面。屏障不会中断流处理，因此非常轻量级。来自不同快照的多个屏障可能同时出现在流中，这意味着多个快照可能并发地发生。

单流的barrier：

多流的barrier：

不止一个输入流的的operator需要在快照屏障上对齐(align)输入流。

在stream source中，流屏障被注入到并发数据流中。快照n被注入屏障的点（简称为Sn），是在source stream中的数据已被纳入该快照后的位置。例如，在Apache Kafka中，该位置将会是partition中最后一条记录的offset。这个Sn的位置将被报告给检查点协调器（Flink JobManager）。

屏障接下来会流向下游。当一个中间的operator从所有它的输入流中接收到一个来自快照n的屏障，它自身发射一个针对快照n的屏障到所有它的输出流。一旦一个sink operator（流DAG的终点）从它所有的输入流中接收到屏障n，它将会像检