Streaming -- State & Fault Tolerance -- Checkpointing

Flink中的每个函数和运算符都可以是有状态的（有关详细信息，请参见使用状态）。有状态功能在处理单个元素/事件的过程中存储数据，使状态成为任何类型的更复杂操作的关键构建块。

为了使状态容错，Flink需要对状态进行检查点。检查点允许Flink恢复流中的状态和位置，从而为应用程序提供与无故障执行相同的语义。

documentation on streaming fault tolerance详细描述了Flink流容错机制背后的技术。

Prerequisites

Flink的检查点机制与流和状态的持久存储交互。一般来说，它需要:

可以在一定时间内重播记录的持续的(或长久的)数据源。这类源的例子有持久的消息队列(例如，Apache Kafka, RabbitMQ, Amazon Kinesis，谷歌PubSub)或文件系统(例如，HDFS, S3, GFS, NFS, Ceph)。
状态的持久存储，通常是分布式文件系统(例如，HDFS、S3、GFS、NFS、Ceph)

Enabling and Configuring Checkpointing

默认情况下，检查点是禁用的。要启用检查点，在StreamExecutionEnvironment上调用enableCheckpointing(n)，其中n是检查点间隔(以毫秒为单位)。

检查点的其他参数包括：

精确一次vs.至少一次:您可以选择将模式传递给enableCheckpointing(n)方法，以便在两个保证级别之间进行选择。对大多数应用程序来说，精确一次是最好的。对于某些超低延迟(始终只有几毫秒)的应用程序，至少需要一次。
检查点超时:如果正在进行的检查点在此之前没有完成，则在此之后中止的时间。
检查点之间的最小时间:为了确保流应用程序在检查点之间取得一定的进展，可以定义检查点之间需要经过多少时间。例如，如果将该值设置为5000，则下一个检查点将在上一个检查点完成后不早于5秒启动，无论检查点持续时间和间隔如何。注意，这意味着检查点间隔永远不会小于此参数。
通过定义检查点之间的时间通常比定义检查点间隔更容易配置应用程序，因为检查点之间的时间不受检查点有时花费的时间超过平均时间这一事实的影响(例如，如果目标存储系统暂时变慢)。
并发检查点的数量:默认情况下，当一个检查点仍在运行时，系统不会触发另一个检查点。这确保拓扑不会在检查点上花费太多时间，也不会在处理流方面取得进步。允许多个重叠的检查点是可能的，这对于具有一定处理延迟(例如，因为函数调用了需要一些时间来响应的外部服务)但仍然希望执行非常频繁的检查点(100毫秒)以在失败时很少重新处理的管道来说是很有趣的。
当定义了检查点之间的最短时间时，不能使用此选项。
外部化检查点:可以配置定期检查点，以在外部持久保存。外部化的检查点将其元数据写入持久存储，并且在作业失败时不会自动清除。这样，如果作业失败，您的周围就会有一个检查点来恢复。在 deployment notes on externalized checkpoints中有更多细节。
检查点错误的失败/继续任务：如果执行任务的检查点过程时发生错误，这将确定任务是否失败。这是默认行为。或者，禁用此选项后，任务将简单地将检查点拒绝给检查点协调器并继续运行。
宁愿使用检查点进行恢复:这决定了一个作业是否将回退到最新的检查点，即使有更多的最近保存点可用来减少恢复时间。

val env = StreamExecutionEnvironment.getExecutionEnvironment()

// start a checkpoint every 1000 ms
env.enableCheckpointing(1000)

// advanced options:

// set mode to exactly-once (this is the default)
env.getCheckpointConfig.setCheckpointingMode(CheckpointingMode.EXACTLY_ONCE)

// make sure 500 ms of progress happen between checkpoints
env.getCheckpointConfig.setMinPauseBetweenCheckpoints(500)

// checkpoints have to complete within one minute, or are discarded
env.getCheckpointConfig.setCheckpointTimeout(60000)

// prevent the tasks from failing if an error happens in their checkpointing, the checkpoint will just be declined.
env.getCheckpointConfig.setFailTasksOnCheckpointingErrors(false)

// allow only one checkpoint to be in progress at the same time
env.getCheckpointConfig.setMaxConcurrentCheckpoints(1)

Related Config Options

可以通过conf / flink-conf.yaml设置更多的参数和/或默认值（请参阅configuration以获取完整指南）：

Key	Default	Type	Description
state.backend	(none)	String	用于存储和检查点状态的状态后端。
state.backend.async	true	Boolean	选项状态后端是否应在可能且可配置的情况下使用异步快照方法。一些状态后端可能不支持异步快照，或者只支持异步快照，并忽略此选项。
state.backend.fs.memory-threshold	1024	Integer	状态数据文件的最小大小。所有小于此值的状态块都内联存储在根检查点元数据文件中。
state.backend.fs.write-buffer-size	4096	Integer	写到文件系统的检查点流的写缓冲区的默认大小。实际的写缓冲区大小被确定为这个选项和选项'state.backend.fs.memory-threshold'的最大值。
state.backend.incremental	false	Boolean	选项状态后端是否应该创建增量检查点(如果可能)。对于增量检查点，只存储与前一个检查点的差异，而不是完整的检查点状态。一些状态后端可能不支持增量检查点并忽略此选项。
state.backend.local-recovery	false	Boolean	此选项配置此状态后端的本地恢复。默认情况下，本地恢复是停用的。本地恢复目前只覆盖键控状态后端。目前，MemoryStateBackend不支持本地恢复并忽略此选项。
state.checkpoints.dir	(none)	String	用于在Flink支持的文件系统中存储检查点的数据文件和元数据的默认目录。必须从所有参与的进程/节点（即所有TaskManager和JobManager）访问存储路径。
state.checkpoints.num-retained	1	Integer	要保留的已完成检查点的最大数量。
state.savepoints.dir	(none)	String	保存点的默认目录。由将保存点写入文件系统的状态后端使用(MemoryStateBackend, FsStateBackend, RocksDBStateBackend)。
taskmanager.state.local.root-dirs	(none)	String	定义根目录的配置参数，用于存储用于本地恢复的基于文件的状态。本地恢复目前只覆盖键控状态后端。目前，MemoryStateBackend不支持本地恢复并忽略此选项

Selecting a State Backend

Flink的checkpointing mechanism在计时器和有状态操作符中存储所有状态的一致快照，包括连接器、窗口和任何用户定义的状态。检查点存储的位置(例如，JobManager内存、文件系统、数据库)取决于配置的状态后端。

默认情况下，状态保存在taskmanager的内存中，检查点存储在JobManager的内存中。为了正确地持久化大状态，Flink支持在其他状态后端存储和检查点状态的各种方法。状态后端可以通过StreamExecutionEnvironment.setStateBackend()配置。

有关可用状态后端以及作业范围和集群范围配置选项的详细信息，请参阅状态后端。

State Checkpoints in Iterative Jobs

Flink目前仅为没有迭代的作业提供处理保证。在迭代作业上启用检查点会导致异常。为了在迭代程序上强制检查点，用户需要在启用检查点时设置一个特殊的标志:env.enableCheckpointing(interval,CheckpointingMode.EXACTLY_ONCE，force = true)。

请注意，在失败期间，循环边缘中的运行记录(以及与它们相关联的状态更改)将丢失。

Restart Strategies

Flink支持不同的重新启动策略，这些策略控制在出现故障时如何重新启动作业。有关更多信息，请参见 Restart Strategies