Flink的检查点算法

Flink的恢复机制基于应用状态的一致检查点。在有状态的流应用中，一个一致性检查点是：在所有tasks处理了一个（相同的）输入后，当前时间点每个task的state副本。

在为application做一个一致性检查点时，一个基本的朴素算法机制如下步骤：

1. 暂停所有输入流的消费。
2. 等待所有未被处理的data完全被处理，表示所有tasks已经处理了它们所有的输入数据。
3. 做检查点：复制每个task的state到一个远端持久性存储。在所有tasks完成了它们的副本后，检查点完成。
4. 恢复消费输入流。

实际上Flink并不是基于上述朴素检查点算法，而是基于Chandy-Lamport算法（用于做分布式快照）实现了检查点机制。此算法并不停止整个应用的运行，而是将做快照的操作从流处理解耦出来，这样一些tasks可以持续运行，而其他tasks可以持久化它们的状态。实现原理：

1. 使用了一个特殊的record类型，称为一个检查点分界（checkpoint barrier）。检查点barriers由source operator注入到常规的流记录中，任务向下游所有分区广播该检查点分界。
2. 任务收到上游分区的barrier后，缓存该分区barrier后的records，直到所有上游分区的barrier都收到后，向JM确认（Acknowledge），在state backend保存检查点，然后广播barrier到该任务的下游tasks。该机制称为alignment机制。
3. 检查点 barriers 到达一个sink task。它会做一个barrier 调整（alignment），给它自己的状态做检查点，并向JM确认它已收到barrier。JobManager在收到一个application的所有task发送的checkpoint acknowledge后，它会记录：此application的检查点完成。
4. 一个source发出的每个分区的数据是FIFO的，保证barrier无法被其他records赶超。多个source或分区的数据顺序由任务的alignment机制保证顺序。
5. 每个检查点barrier会携带一个检查点ID，用于辨别它属于哪个检查点，并且将一个流在逻辑上分成两部分。

应用恢复到检查点状态的步骤：

1. 重启整个application。
2. 重置所有stateful tasks的状态为最近的检查点。
3. 恢复所有tasks的处理。

数据源是否支持重置取决于它的实现（CDC连接器），以及流被消费的源头。例如，Kafka可以提供一个流中当前偏移量之前的records，从socket消费的，则无法被重置，因为sockets在消费完一个数据后会将它丢弃。因此，一个application在仅当所有输入流是由可重置的 data sources 消费时，它才能够以 exactly-once state 一致性的方式运行。

Flink的检查点与恢复机制仅重置一个流应用的internal state。在恢复时，取决于应用的sink operator的不同，一些records可能会多次释放给下游的流，例如一个event log，一个文件系统，或是一个数据库。对于某些存储系统，Flink的sink 函数可以提供 exactly-once 输出，例如，在检查点完成时才提交释放的records。另一个适用于大部分存储系统的方法是：幂等更新（idempotent updates）。