什么是状态？#
虽然数据流中的许多操作通常一次仅处理单个事件（例如事件解析器），但有些操作会在多个事件间记住相关信息（例如窗口操作符）。这些操作被称为有状态操作。
有状态操作的一些示例：
- 当应用程序搜索特定的事件模式时，状态会存储到目前为止遇到的事件序列。
- 按分钟 / 小时 / 天聚合事件时，状态保存待处理的聚合结果。
- 在一系列数据点上训练机器学习模型时，状态保存模型参数的当前版本。
- 当需要管理历史数据时，状态允许高效访问过去发生的事件。
Flink 需要了解状态，以便使用检查点和保存点实现容错。
了解状态还有助于对 Flink 应用程序进行重新缩放，这意味着 Flink 会负责在并行实例间重新分配状态。
可查询状态允许你在运行时从 Flink 外部访问状态。
在处理状态时，了解 Flink 的状态后端可能也会有所帮助。Flink 提供了不同的状态后端，用于指定状态的存储方式和存储位置。
键控状态 #
键控状态维护在一个可视为嵌入式键值存储的结构中。状态与有状态操作符读取的流严格分区并一起分布。因此，仅在键控流上才能访问键值状态，即在进行键控 / 分区数据交换之后，并且只能访问与当前事件的键相关联的值。将流的键与状态的键对齐，可确保所有状态更新都是本地操作，无需事务开销即可保证一致性。这种对齐还使 Flink 能够透明地重新分配状态并调整流分区。
状态与分区
键控状态进一步组织为所谓的键组。键组是 Flink 重新分配键控状态的基本单元；键组的数量与定义的最大并行度完全相同。在执行过程中，键控操作符的每个并行实例处理一个或多个键组的键。
状态持久性#
Flink 通过流重放和检查点相结合的方式实现容错。一个检查点标记每个输入流中的特定点，以及每个操作符的相应状态。通过恢复操作符的状态并从检查点处重新播放记录，流数据流可以从检查点恢复，同时保持一致性（精确一次处理语义）。
检查点间隔是在执行期间容错开销与恢复时间（需要重新播放的记录数）之间进行权衡的一种方式。
容错机制持续对分布式流数据流进行快照。对于状态较小的流应用程序，这些快照非常轻量级，可以频繁进行，而对性能影响不大。流应用程序的状态存储在可配置的位置，通常是分布式文件系统中。
如果程序发生故障（由于机器、网络或软件故障），Flink 会停止分布式流数据流。然后系统重新启动操作符，并将它们重置到最近一次成功的检查点。输入流被重置到状态快照的位置。作为重新启动的并行数据流一部分处理的任何记录，都保证不会影响先前检查点的状态。
默认情况下，检查点功能是禁用的。有关如何启用和配置检查点的详细信息，请参阅 “检查点”。
为使此机制充分发挥其保证作用，数据流源（如消息队列或代理）需要能够将流倒回到最近定义的点。Apache Kafka 具备此能力，Flink 与 Kafka 的连接器利用了这一点。有关 Flink 连接器提供的保证的更多信息，请参阅 “数据源和接收器的容错保证”。
由于 Flink 的检查点是通过分布式快照实现的，我们可互换使用 “快照” 和 “检查点” 这两个词。通常我们也用 “快照” 一词来指代检查点或保存点。
检查点#
Flink 容错机制的核心部分是对分布式数据流和操作符状态进行一致性快照。这些快照作为一致性检查点，系统在发生故障时可以回退到这些检查点。Flink 进行这些快照的机制在《分布式数据流的轻量级异步快照》中有描述。它受标准的 Chandy – Lamport 分布式快照算法启发，并专门针对 Flink 的执行模型进行了定制。
请记住，与检查点相关的所有操作都可以异步完成。检查点屏障不会同步移动，操作可以异步对其状态进行快照。
自 Flink 1.11 起，检查点可以在有对齐或无对齐的情况下进行。在本节中，我们先描述对齐检查点。
屏障#
Flink 分布式快照中的一个核心元素是流屏障。这些屏障被注入到数据流中，并作为数据流的一部分与记录一起流动。屏障永远不会超过记录，它们严格按顺序流动。一个屏障将数据流中的记录分为进入当前快照的记录集和进入下一个快照的记录集。每个屏障携带它前面推送的快照的 ID。屏障不会中断流的流动，因此非常轻量级。来自不同快照的多个屏障可以同时存在于流中，这意味着各种快照可以并发发生。
数据流中的检查点屏障：流屏障在流源处被注入到并行数据流中。注入快照 n 的屏障的点（我们称之为 Sn）是源流中快照覆盖数据的位置。例如，在 Apache Kafka 中，这个位置将是分区中最后一条记录的偏移量。这个位置 Sn 会报告给检查点协调器（Flink 的 JobManager）。
然后屏障向下游流动。当一个中间操作符从其所有输入流接收到快照 n 的屏障时，它会向其所有输出流发送一个快照 n 的屏障。一旦一个接收器操作符（流 DAG 的末端）从其所有输入流接收到屏障 n，它就会向检查点协调器确认快照 n。在所有接收器都确认一个快照后，该快照被视为完成。
一旦快照 n 完成，作业将不再要求源提供 Sn 之前的记录，因为此时这些记录（及其衍生记录）将已经通过整个数据流拓扑。
在具有多个输入的操作符处对齐数据流：接收多个输入流的操作符需要在快照屏障上对齐输入流。上图说明了这一点：
- 一旦操作符从传入流接收到快照屏障 n，在它也从其他输入接收到屏障 n 之前，它不能处理来自该流的任何更多记录。否则，它会将属于快照 n 的记录与属于快照 n + 1 的记录混合。
- 一旦最后一个流接收到屏障 n，操作符会发出所有挂起的输出记录，然后自己发出快照 n 屏障。
- 它对状态进行快照，并从所有输入流恢复处理记录，在处理来自流的记录之前先处理输入缓冲区中的记录。
- 最后，操作符将状态异步写入状态后端。
请注意，所有具有多个输入的操作符以及在洗牌后消耗多个上游子任务输出流的操作符都需要进行对齐。
操作符状态快照#
当操作符包含任何形式的状态时，此状态也必须是快照的一部分。
操作符在从其输入流接收到所有快照屏障的时间点，并且在向其输出流发送屏障之前，对其状态进行快照。在该时间点，已经对屏障之前的记录进行了所有状态更新，并且尚未应用依赖于屏障之后记录的更新。由于快照的状态可能很大，它存储在可配置的状态后端中。默认情况下，这是 JobManager 的内存，但对于生产使用，应配置分布式可靠存储（如 HDFS）。在状态存储之后，操作符确认检查点，向输出流发送快照屏障，然后继续执行。
生成的快照现在包含：
- 对于每个并行流数据源，启动快照时流中的偏移量 / 位置。
- 对于每个操作符，指向作为快照一部分存储的状态的指针。
检查点机制图示
恢复#
在此机制下的恢复很简单：发生故障时，Flink 选择最新完成的检查点 k。然后系统重新部署整个分布式数据流，并为每个操作符提供作为检查点 k 一部分进行快照的状态。源被设置为从位置 Sk 开始读取流。例如在 Apache Kafka 中，这意味着告诉消费者从偏移量 Sk 开始获取数据。
如果状态是增量快照的，操作符从最新的完整快照状态开始，然后对该状态应用一系列增量快照更新。
有关更多信息，请参阅 “重启策略”。
非对齐检查点#
检查点也可以以非对齐方式执行。基本思想是，只要飞行中的数据成为操作符状态的一部分，检查点就可以超过所有飞行中的数据。
请注意，这种方法实际上更接近 Chandy – Lamport 算法，但 Flink 仍然在源中插入屏障，以避免使检查点协调器过载。
非对齐检查点：该图展示了一个操作符如何处理非对齐检查点屏障：
- 操作符对存储在其输入缓冲区中的第一个屏障做出反应。
- 它立即通过将屏障添加到输出缓冲区的末尾，将其转发到下游操作符。
- 操作符标记所有被超过的记录以异步存储，并创建自己状态的快照。
- 因此，操作符仅短暂停止输入处理以标记缓冲区、转发屏障并创建其他状态的快照。
非对齐检查点确保屏障尽快到达接收器。它特别适用于至少有一个缓慢移动数据路径的应用程序，在这种情况下对齐时间可能长达数小时。但是，由于它会增加额外的 I/O 压力，当到状态后端的 I/O 成为瓶颈时，它并无帮助。有关其他限制，请参阅操作中的更深入讨论。
请注意，保存点始终是对齐的。
非对齐恢复#
在非对齐检查点中，操作符在开始处理来自上游操作符的任何数据之前，首先恢复飞行中的数据。除此之外，它执行与对齐检查点恢复期间相同的步骤。
状态后端#
键 / 值索引存储的确切数据结构取决于所选的状态后端。一种状态后端将数据存储在内存哈希表中，另一种状态后端使用 RocksDB 作为键值存储。除了定义保存状态的数据结构之外，状态后端还实现了对键值状态进行时间点快照并将该快照作为检查点一部分存储的逻辑。可以在不更改应用程序逻辑的情况下配置状态后端。
检查点和快照
保存点#
所有使用检查点的程序都可以从保存点恢复执行。保存点允许在不丢失任何状态的情况下更新程序和 Flink 集群。
保存点是手动触发的检查点，它对程序进行快照并将其写入状态后端。它们依赖于常规的检查点机制来实现这一点。
保存点与检查点类似，不同之处在于它们由用户触发，并且在新的检查点完成时不会自动过期。为了正确使用保存点，了解检查点与保存点之间的区别非常重要，“检查点与保存点” 中对此进行了描述。
精确一次与至少一次#
对齐步骤可能会给流程序增加延迟。通常，这种额外延迟在几毫秒量级，但我们也看到过一些异常值的延迟明显增加的情况。对于要求所有记录始终具有超低延迟（几毫秒）的应用程序，Flink 提供了一个开关，可在检查点期间跳过流对齐。一旦操作符从每个输入看到检查点屏障，仍会立即进行检查点快照。
当跳过对齐时，即使在检查点 n 的一些检查点屏障到达后，操作符仍会继续处理所有输入。这样，在为检查点 n 拍摄状态快照之前，操作符也会处理属于检查点 n + 1 的元素。在恢复时，这些记录将作为重复项出现，因为它们既包含在检查点 n 的状态快照中，又将作为检查点 n 之后的数据的一部分被重新播放。
仅对于具有多个前驱（连接）的操作符以及具有多个发送者（在流重新分区 / 洗牌之后）的操作符才会发生对齐。因此，仅包含易于并行的流操作（map ()、flatMap ()、filter () 等）的数据流实际上即使在至少一次模式下也能提供精确一次的保证。
批处理程序中的状态与容错#
Flink 将批处理程序作为流程序的一种特殊情况执行，其中流是有界的（元素数量有限）。DataSet 在内部被视为数据流。因此，上述概念同样适用于批处理程序，与适用于流程序的方式相同，但有一些小的例外：
- 批处理程序的容错不使用检查点。恢复通过完全重放流来实现。这是可行的，因为输入是有界的。这将成本更多地推向恢复阶段，但使常规处理更便宜，因为它避免了检查点。
- DataSet API 中的有状态操作使用简化的内存 / 外存数据结构，而不是键 / 值索引。
- DataSet API 引入了特殊的同步（基于超步）迭代，这仅在有界流上才可行。有关详细信息，请查看迭代文档。