Apache Flink提供了一种容错机制，可以持续恢复数据流应用程序的状态。该机制确保即使出现故障，程序的状态最终也会反映来自数据流的每条记录只有一次。
容错机制连续绘制了分布式流数据流的快照。对于小状态的流应用程序，这些快照非常轻量级并且可以经常绘制，而不会对性能产生太大的影响。流应用程序的状态存储在一个可配置的地方(例如主节点或HDFS)。
如果出现程序故障(由于机器、网络或软件故障)，Flink将停止分布式流数据流。然后系统重新启动操作符并将其重新设置为最新成功的检查点。输入流被重置到状态快照的点。默认情况下，检查点是禁用的。
要使此机制实现其全部的保证，数据流源(如消息队列或代理)需要能够将流倒回到其定义的最近点。Apache Kafka可以做到，而Flink的Kafka连接器可以利用这些。
因为Flink通过分布式检查点实现快照，我们使用快照和检查点互换。
checkpointing：
- Flink容错机制的核心部分是绘制分布式数据流和操作符状态的一致的快照。这些快照充当一致的检查点，在出现故障时系统可以退回到检查点。
- Barriers：Flink的分布式快照的核心元素是stream barriers。这些barriers被注入到数据流中和记录一样作为数据流的一部分流动。Barriers从不会超过记录。Barriers将数据流中的记录分为进入当前快照的记录集和进入下一个快照的记录。每个barriers都带有快照的ID，该快照的记录在其前面推送。Barriers不会阻断流的流动。
流barriers被注入到流数据源的并行数据流中，快照n的barriers(我们称之为Sn)被注入的点是源流中快照覆盖数据的位置。例如，在Apache Kafka中，此位置是分区中最后一条记录的偏移量。该位置Sn被报告给Flink的JobManager。然后barriers继续流动，当中间操作符从其所有输入流都收到快照n的barriers时，他会向所有输出流发出(emit)快照n的barriers。一旦操作符接收器(流DAG的末端)从它的所有输入流接收到barrier n，它就向快照n确认检查点协调器。在所有接收器确认快照后，它被视为已完成。一旦完成快照n，作业将永远不再向源请求来自Sn之前的记录，因为此时这些记录(及其后代记录)将通过整个数据流拓扑。
接收多个输入流的运算符需要在快照barriers上对齐输入流。上图说明了这一点： - 一旦操作员从输入流接收到快照barriers n，它就不能处理来自该流的任何其他记录(而是缓存)，直到它从其他输入接收到barrier n为止。否则它会混合属于快照n和属于快照n + 1的记录。(begin aligning - aligning)
- 报告barrier n的流暂时被搁置。从这些流接收的记录不会被处理，而是放入输入缓冲区。(aligning)
- 一旦最后一个输入流接收到barrier n，操作符就会发出所有挂起的传出记录，然后自己发出快照n的barriers。(checkpoint - continue)
- 之后，它恢复处理来自所有输入流的记录，在处理来自流的记录之前处理来自输入缓冲区的记录。(continue)
- State：当运算符包含任何形式的状态时，此状态也必须是快照的一部分。运算符状态有不同的形式：
- 用户定义的状态：这是由转换函数(如
map()或filter())直接创建和修改的状态。 - 系统状态：此状态是指作为运算符计算一部分的数据缓冲区。此状态的典型示例是窗口缓冲区，系统在其中收集(和聚合)窗口记录，直到窗口被评估和逐出。 操作员在他们从输入流接收到所有快照barriers时，立即在向其输出流发出barriers之前对其状态进行快照。此时，将根据barriers之前的记录对状态进行所有更新，并且在应用barriers之后不依赖于记录的更新。由于快照的状态可能很大，因此它存储在可配置的状态后端(state backend)中。默认情况下，这是JobManager的内存，但对于生产使用，应配置分布式可靠存储(例如HDFS)。在存储状态之后，运算符确认检查点，将快照barriers发送到输出流中，然后继续。 生成的快照现在包含：
- 对于每个并行流数据源，启动快照时流中的偏移/位置。
- 对于每个运算符，指向作为快照的一部分存储的状态的指针。
- 仅有一次或至少一次：