Flink容错机制（一）

目录

十：容错机制

10.1 检查点（Checkpoint）

10.1.1 检查点的保存

10.1.2 从检查点恢复状态

 10.1.3 检查点算法

 10.1.4 检查点配置

10.1.5 保存点（Savepoint）

---

十：容错机制

流式数据连续不断地到来，无休无止；所以流处理程序也是持续运行的，并没有一个明确 的结束退出时间。机器运行程序，996 起来当然比人要容易得多，不过希望“永远运行”也是 不切实际的。因为各种硬件软件的原因，运行一段时间后程序可能异常退出、机器可能宕机， 如果我们只依赖一台机器来运行，就会使得任务的处理被迫中断。

一个解决方案就是多台机器组成集群，以“分布式架构”来运行程序。这样不仅扩展了系 统的并行处理能力，而且可以解决单点故障的问题，从而大大提高系统的稳定性和可用性。

在分布式架构中，当某个节点出现故障，其他节点基本不受影响。这时只需要重启应用， 恢复之前某个时间点的状态继续处理就可以了。这一切看似简单，可是在实时流处理中，我们 不仅需要保证故障后能够重启继续运行，还要保证结果的正确性、故障恢复的速度、对处理性 能的影响，这就需要在架构上做出更加精巧的设计。

在 Flink 中，有一套完整的容错机制（fault tolerance）来保证故障后的恢复，其中最重要 的就是检查点（checkpoint）。在第九章中，我们已经介绍过检查点的基本概念和用途，接下来 我们就深入探讨一下检查点的原理和 Flink 的容错机制。

10.1 检查点（Checkpoint）

发生故障之后怎么办？最简单的想法当然是重启机器、重启应用。由于是分布式的集群， 即使一个节点无法恢复，也不会影响应用的重启执行。这里的问题在于，流处理应用中的任务 都是有状态的，而为了快速访问这些状态一般会直接放在堆内存里；现在重启应用，内存中的 状态已经丢失，就意味着之前的计算全部白费了，需要从头来过。就像编写文档或是玩 RPG游戏，因为宕机没保存而要重来一遍是一件令人崩溃的事情；这种惨痛的经历让我们养成了一 个好习惯——随时存档，这样即使遇到宕机也可以读档继续了。

在流处理中，我们同样可以用存档读档的思路，把之前的计算结果做个保存，这样重启之 后就可以继续处理新数据、而不需要重新计算了。进一步地，我们知道在有状态的流处理中， 任务继续处理新数据，并不需要“之前的计算结果”，而是需要任务“之前的状态”。所以我们 最终的选择，就是将之前某个时间点所有的状态保存下来，这份“存档”就是所谓的“检查点” （checkpoint）。

遇到故障重启的时候，我们可以从检查点中“读档”，恢复出之前的状态，这样就可以回 到当时保存的一刻接着处理数据了。

检查点是 Flink 容错机制的核心。这里所谓的“检查”，其实是针对故障恢复的结果而言 的：故障恢复之后继续处理的结果，应该与发生故障前完全一致，我们需要“检查”结果的正 确性。所以，有时又会把 checkpoint 叫作“一致性检查点”。

10.1.1 检查点的保存

1. 周期性的触发保存

“随时存档”确实恢复起来方便，可是需要我们不停地做存档操作。如果每处理一条数据 就进行检查点的保存，当大量数据同时到来时，就会耗费很多资源来频繁做检查点，数据处理 的速度就会受到影响。

所以更好的方式是，每隔一段时间去做一次存档，这样既不会影响数据 的正常处理，也不会有太大的延迟——毕竟故障恢复的情况不是随时发生的。在 Flink 中，检查点的保存是周期性触发的，间隔时间可以进行设置。

所以检查点作为应用状态的一份“存档”，其实就是所有任务状态在同一时间点的一个“快照”（snapshot），它的触发是周期性的。具体来说，当每隔一段时间检查点保存操作被触发时， 就把每个任务当前的状态复制一份，按照一定的逻辑结构放在一起持久化保存起来，就构成了检查点。

2. 保存的时间点

这里有一个关键问题：当检查点的保存被触发时，任务有可能正在处理某个数据，这时该怎么办呢？

方案：（如果一个数据被所有任务处理完，则保存状态，否则，恢复到之前保存的状态，然后故障恢复后，重新提交任务）

当所有任务都恰好处理完一个相同的输入数据的时候，将它们的状态保存下来。首先，这样避免了除状态之外其他额外信息的存储，提高了检查点保存的效率。 其次，一个数据要么就是被所有任务完整地处理完，状态得到了保存；要么就是没处理完，状态全部没保存：这就相当于构建了一个“事务”（transaction）。如果出现故障，我们恢复到之前保存的状态，故障时正在处理的所有数据都需要重新处理；所以我们只需要让源（source） 任务向数据源重新提交偏移量、请求重放数据就可以了。这需要源任务可以把偏移量作为算子状态保存下来，而且外部数据源能够重置偏移量；Kafka 就是满足这些要求的一个最好的例子。

3. 保存的具体流程  

检查点的保存，最关键的就是要等所有任务将“同一个数据”处理完毕。下面我们通过一 个具体的例子，来详细描述一下检查点具体的保存过程。

回忆一下我们最初实现的统计词频的程序——WordCount。这里为了方便，我们直接从数 据源读入已经分开的一个个单词，例如这里输入的就是：

“hello”“world”“hello”“flink”“hello”“world”“hello”“flink”……

对应的代码就可以简化为：

SingleOutputStreamOperator> wordCountStream = 
env.addSource(...) 
 .map(word -> Tuple2.of(word, 1L)) 
 .returns(Types.TUPLE(Types.STRING, Types.LONG)); 
 .keyBy(t -> t.f0); 
 .sum(1); 

源（Source）任务从外部数据源读取数据，并记录当前的偏移量，作为算子状态（Operator State）保存下来。然后将数据发给下游的 Map 任务，它会将一个单词转换成(word, count)二元 组，初始 count 都是 1，也就是(“hello”, 1)、(“world”, 1)这样的形式；这是一个无状态的算子任 务。进而以 word 作为键（key）进行分区，调用.sum()方法就可以对 count 值进行求和统计了；Sum 算子会把当前求和的结果作为按键分区状态（Keyed State）保存下来。最后得到的就是当 前单词的频次统计(word, count)

当我们需要保存检查点（checkpoint）时，就是在所有任务处理完同一条数据后，对状态做个快照保存下来。例如上图中，已经处理了 3 条数据：“hello”“world”“hello”，所以我们 会看到 Source 算子的偏移量为 3；后面的 Sum 算子处理完第三条数据“hello”之后，此时已 经有 2 个“hello”和 1 个“world”，所以对应的状态为“hello”-> 2，“world”-> 1（这里 KeyedState底层会以 key-value 形式存储）。

此时所有任务都已经处理完了前三个数据，所以我们可以把当前的状态保存成一个检查点，写入外部存储中。

至于具体保存到哪里，这是由状态后端的配置项 “ 检查点存储 ”（ CheckpointStorage ）来决定的，可以有作业管理器的堆内存 （JobManagerCheckpointStorage）和文件系统（FileSystemCheckpointStorage）两种选择。一般 情况下，我们会将检查点写入持久化的分布式文件系统。

10.1.2 从检查点恢复状态

在运行流处理程序时，Flink 会周期性地保存检查点。当发生故障时，就需要找到最近一次成功保存的检查点来恢复状态。

例如在上节的 word count 示例中，我们处理完三个数据后保存了一个检查点。之后继续运行，又正常处理了一个数据“flink”，在处理第五个数据“hello”时发生了故障。

 

这里 Source 任务已经处理完毕，所以偏移量为 5；Map 任务也处理完成了。而 Sum 任务 在处理中发生了故障，此时状态并未保存。

接下来就需要从检查点来恢复状态了。具体的步骤为：

（1）重启应用

遇到故障之后，第一步当然就是重启。我们将应用重新启动后，所有任务的状态会清空.

（2）读取检查点，重置状态

找到最近一次保存的检查点，从中读出每个算子任务状态的快照，分别填充到对应的状态中。这样，Flink 内部所有任务的状态，就恢复到了保存检查点的那一时刻，也就是刚好处理完第三个数据的时候。

这里 key 为“flink”并没有数据到来，所以初始为 0。

（3）重放数据

从检查点恢复状态后还有一个问题：如果直接继续处理数据，那么保存检查点之后、到发生故障这段时间内的数据，也就是第 4、5 个数据（“flink”“hello”）就相当于丢掉了；这会造成计算结果的错误。

为了不丢数据，我们应该从保存检查点后开始重新读取数据，这可以通过 Source 任务向 外部数据源重新提交偏移量（offset）来实现

这样，整个系统的状态已经完全回退到了检查点保存完成的那一时刻。

（4）继续处理数据

接下来，我们就可以正常处理数据了。首先是重放第 4、5 个数据，然后继续读取后面的数据

当处理到第 5 个数据时，就已经追上了发生故障时的系统状态。

之后继续处理，就好像没 有发生过故障一样；我们既没有丢掉数据也没有重复计算数据，这就保证了计算结果的正确性。 在分布式系统中，这叫作实现了“精确一次”（exactly-once）的状态一致性保证。 

 这里我们也可以发现，想要正确地从检查点中读取并恢复状态，必须知道每个算子任务状态的类型和它们的先后顺序（拓扑结构）；因此为了可以从之前的检查点中恢复状态，我们在 改动程序、修复 bug 时要保证状态的拓扑顺序和类型不变。状态的拓扑结构在 JobManager 上 可以由 JobGraph 分析得到，而检查点保存的定期触发也是由 JobManager 控制的；所以故障恢 复的过程需要 JobManager 的参与。

 10.1.3 检查点算法

我们已经知道，Flink 保存检查点的时间点，是所有任务都处理完同一个输入数据的时候。 但是不同的任务处理数据的速度不同，当第一个 Source 任务处理到某个数据时，后面的 Sum任务可能还在处理之前的数据；而且数据经过任务处理之后类型和值都会发生变化，面对着“面 目全非”的数据，不同的任务怎么知道处理的是“同一个”呢？

一个简单的想法是，当接到 JobManager 发出的保存检查点的指令后，Source 算子任务处理完当前数据就暂停等待，不再读取新的数据了。这样我们就可以保证在流中只有需要保存到检查点的数据，只要把它们全部处理完，就可以保证所有任务刚好处理完最后一个数据；这时把所有状态保存起来，合并之后就是一个检查点了。这就好比我们想要保存所有同学刚好毕业时的状态，那就在所有人答辩完成之后，集合起来拍一张毕业合照。这样做最大的问题，就是 每个人的进度可能不同；先答辩完的人为了保证状态一致不能进行其他工作，只能等待。当先保存完状态的任务需要等待其他任务时，就导致了资源的闲置和性能的降低。

所以更好的做法是，在不暂停整体流处理的前提下，将状态备份保存到检查点。在 Flink中，采用了基于 Chandy-Lamport 算法的分布式快照。

 1. 检查点分界线（Barrier）

我们现在的目标是，在不暂停流处理的前提下，让每个任务“认出”触发检查点保存的那个数据。

自然想到，如果给数据添加一个特殊标识，任务就可以准确识别并开始保存状态了。这需 要在 Source 任务收到触发检查点保存的指令后，立即在当前处理的数据中插入一个标识字段， 然后再向下游任务发出。但是假如 Source 任务此时并没有正在处理的数据，这个操作就无法 实现了。

所以我们可以借鉴水位线（watermark）的设计，在数据流中插入一个特殊的数据结构， 专门用来表示触发检查点保存的时间点。收到保存检查点的指令后，Source 任务可以在当前 数据流中插入这个结构；之后的所有任务只要遇到它就开始对状态做持久化快照保存。

由于数据流是保持顺序依次处理的，因此遇到这个标识就代表之前的数据都处理完了，可以保存一个 检查点；而在它之后的数据，引起的状态改变就不会体现在这个检查点中，而需要保存到下一 个检查点。

这种特殊的数据形式，把一条流上的数据按照不同的检查点分隔开，所以就叫作检查点的 “分界线”（Checkpoint Barrier）。

与水位线很类似，检查点分界线也是一条特殊的数据，由 Source 算子注入到常规的数据 流中，它的位置是限定好的，不能超过其他数据，也不能被后面的数据超过。检查点分界线中 带有一个检查点 ID，这是当前要保存的检查点的唯一标识。

这样，分界线就将一条流逻辑上分成了两部分：分界线之前到来的数据导致的状态更改， 都会被包含在当前分界线所表示的检查点中；而基于分界线之后的数据导致的状态更改，则会 被包含在之后的检查点中。

在 JobManager 中有一个“检查点协调器”（checkpoint coordinator），专门用来协调处理检 查点的相关工作。

检查点协调器会定期向 TaskManager 发出指令，要求保存检查点（带着检查 点 ID）；TaskManager 会让所有的 Source 任务把自己的偏移量（算子状态）保存起来，并将带 有检查点 ID 的分界线（barrier）插入到当前的数据流中，然后像正常的数据一样像下游传递； 之后 Source 任务就可以继续读入新的数据了。

每个算子任务只要处理到这个 barrier，就把当前的状态进行快照；在收到 barrier 之前， 还是正常地处理之前的数据，完全不受影响。比如上图中，Source 任务收到 1 号检查点保存 指令时，读取完了三个数据，所以将偏移量 3 保存到外部存储中；而后将 ID 为 1 的 barrier 注 入数据流；与此同时，Map 任务刚刚收到上一条数据“hello”，而 Sum 任务则还在处理之前的 第二条数据(world, 1)。下游任务不会在这时就立刻保存状态，而是等收到 barrier 时才去做快照，这时可以保证前三个数据都已经处理完了。同样地，下游任务做状态快照时，也不会影响上游任务的处理，每个任务的快照保存并行不悖，不会有暂停等待的时间。

如果还是拿拍毕业照来类比的话，现在就不需要大家答辩完之后聚在一起排队摆 pose 了 ——每个人完成答辩之后只要单独照张相，就可以继续做自己的事情去了；最后由班主任老师 发挥 P 图技能合成合照，这样无疑就省去了大家集合等待的时间。

2. 分布式快照算法

通过在流中插入分界线（barrier），我们可以明确地指示触发检查点保存的时间。在一条 单一的流上，数据依次进行处理，顺序保持不变；不过对于分布式流处理来说，想要一直保持 数据的顺序就不是那么容易了。

我们先回忆一下水位线（watermark）的处理：上游任务向多个并行下游任务传递时，需 要广播出去；而多个上游任务向同一个下游任务传递时，则需要下游任务为每个上游并行任务 维护一个“分区水位线”，取其中最小的那个作为当前任务的事件时钟。

那 barier 在并行数据流中的传递，是不是也有类似的规则呢？ watermark 指示的是“之前的数据全部到齐了”，而 barrier 指示的是“之前所有数据的状态更改保存入当前检查点”：它们都是一个“截止时间”的标志。所以在处理多个分区的传递 时，也要以是否还会有数据到来作为一个判断标准。

具体实现上，Flink 使用了 Chandy-Lamport 算法的一种变体，被称为“异步分界线快照” （asynchronous barrier snapshotting）算法。

算法的核心就是两个原则：当上游任务向多个并行 下游任务发送 barrier 时，需要广播出去；而当多个上游任务向同一个下游任务传递 barrier 时， 需要在下游任务执行“分界线对齐”（barrier alignment）操作，也就是需要等到所有并行分区 的 barrier 都到齐，才可以开始状态的保存。

为了详细解释检查点算法的原理，我们对之前的 word count 程序进行扩展，考虑所有算子并行度为 2 的场景。

我们有两个并行的 Source 任务，会分别读取两个数据流（或者是一个源的不同分区）。这里每条流中的数据都是一个个的单词：“hello”“world”“hello”“flink”交替出现。此时第一 条流的 Source 任务（为了方便，下文中我们直接叫它“Source 1”，其他任务类似）读取了 3

个数据，偏移量为 3；而第二条流的 Source 任务（Source 2）只读取了一个“hello”数据，偏移量为 1。第一条流中的第一个数据“hello”已经完全处理完毕，所以 Sum 任务的状态中 key为 hello 对应着值 1，而且已经发出了结果(hello, 1)；第二个数据“world”经过了 Map 任务的 转换，还在被 Sum 任务处理；第三个数据“hello”还在被 Map 任务处理。而第二条流的第一 个数据“hello”同样已经经过了 Map 转换，正在被 Sum 任务处理。

接下来就是检查点保存的算法。具体过程如下：

（1）JobManager 发送指令，触发检查点的保存

Source 任务保存状态，插入分界线 JobManager 会周期性地向每个 TaskManager 发送一条带有新检查点 ID 的消息，通过这种方式来启动检查点。收到指令后，TaskManger 会在所有 Source 任务中插入一个分界线 （barrier），并将偏移量保存到远程的持久化存储中。

 

并行的 Source 任务保存的状态为 3 和 1，表示当前的 1 号检查点应该包含：第一条流中截至第三个数据、第二条流中截至第一个数据的所有状态更改。可以发现 Source 任务做这些 的时候并不影响后面任务的处理，Sum 任务已经处理完了第一条流中传来的(world, 1)，对应的状态也有了更改。

（2）状态快照保存完成，分界线向下游传递

状态存入持久化存储之后，会返回通知给 Source 任务；Source 任务就会向 JobManager确认检查点完成，然后像数据一样把 barrier 向下游任务传递。

由于 Source 和 Map 之间是一对一（forward）的传输关系（这里没有考虑算子链 operator chain），所以 barrier 可以直接传递给对应的 Map 任务。之后 Source 任务就可以继续读取新的数据了。与此同时，Sum 1 已经将第二条流传来的(hello，1)处理完毕，更新了状态。

（3）向下游多个并行子任务广播分界线，执行分界线对齐 Map 任务没有状态，所以直接将 barrier 继续向下游传递。

这时由于进行了 keyBy 分区， 所以需要将 barrier 广播到下游并行的两个 Sum 任务，如图所示。同时，Sum 任务可能 收到来自上游两个并行 Map 任务的 barrier，所以需要执行“分界线对齐”操作。

此时的 Sum 2 收到了来自上游两个 Map 任务的 barrier，说明第一条流第三个数据、第二 条流第一个数据都已经处理完，可以进行状态的保存了；而 Sum 1 只收到了来自 Map 2 的barrier，所以这时需要等待分界线对齐。在等待的过程中，如果分界线尚未到达的分区任务Map 1 又传来了数据(hello, 1)，说明这是需要保存到检查点的，Sum 任务应该正常继续处理数据，状态更新为 3；而如果分界线已经到达的分区任务 Map 2 又传来数据，这已经是下一个检 查点要保存的内容了，就不应立即处理，而是要缓存起来、等到状态保存之后再做处理。

（4）分界线对齐后，保存状态到持久化存储

各个分区的分界线都对齐后，就可以对当前状态做快照，保存到持久化存储了。存储完成 之后，同样将 barrier 向下游继续传递，并通知 JobManager 保存完毕。

这个过程中，每个任务保存自己的状态都是相对独立的，互不影响。我们可以看到，当Sum 将当前状态保存完毕时，Source 1 任务已经读取到第一条流的第五个数据了。

（5）先处理缓存数据，然后正常继续处理

完成检查点保存之后，任务就可以继续正常处理数据了。这时如果有等待分界线对齐时缓存的数据，需要先做处理；然后再按照顺序依次处理新到的数据。

当 JobManager 收到所有任务成功保存状态的信息，就可以确认当前检查点成功保存。之 后遇到故障就可以从这里恢复了。

由于分界线对齐要求先到达的分区做缓存等待，一定程度上会影响处理的速度；当出现背压（backpressure）时，下游任务会堆积大量的缓冲数据，检查点可能需要很久才可以保存完 毕。为了应对这种场景，Flink 1.11 之后提供了不对齐的检查点保存方式，可以将未处理的缓 冲数据（in-flight data）也保存进检查点。这样，当我们遇到一个分区 barrier 时就不需等待对齐，而是可以直接启动状态的保存了。

 10.1.4 检查点配置

检查点的作用是为了故障恢复，我们不能因为保存检查点占据了大量时间、导致数据处理 性能明显降低。为了兼顾容错性和处理性能，我们可以在代码中对检查点进行各种配置。

1. 启用检查点

默认情况下，Flink 程序是禁用检查点的。如果想要为 Flink 应用开启自动保存快照的功能，需要在代码中显式地调用执行环境的.enableCheckpointing()方法：

StreamExecutionEnvironment env = 
StreamExecutionEnvironment.getExecutionEnvironment(); 
// 每隔 1 秒启动一次检查点保存 
env.enableCheckpointing(1000); 

这里需要传入一个长整型的毫秒数，表示周期性保存检查点的间隔时间。如果不传参数直 接启用检查点，默认的间隔周期为 500 毫秒，这种方式已经被弃用。

检查点的间隔时间是对处理性能和故障恢复速度的一个权衡。如果我们希望对性能的影响更小，可以调大间隔时间；而如果希望故障重启后迅速赶上实时的数据处理，就需要将间隔时间设小一些。

2. 检查点存储（Checkpoint Storage）

检查点具体的持久化存储位置，取决于“检查点存储”（CheckpointStorage）的设置。默认情况下，检查点存储在 JobManager 的堆（heap）内存中。而对于大状态的持久化保存，Flink也提供了在其他存储位置进行保存的接口，这就是 CheckpointStorage。具体 可以通过调用检查点配置的 .setCheckpointStorage() 来 配 置 ， 需 要 传 入一 个CheckpointStorage 的实现类。

Flink 主要提供了两种 CheckpointStorage：

一：作业管理器的堆内存 （JobManagerCheckpointStorage）

二：文件系统（FileSystemCheckpointStorage）

// 配置存储检查点到 JobManager 堆内存 
env.getCheckpointConfig().setCheckpointStorage(new JobManagerCheckpointStorage()); 
// 配置存储检查点到文件系统 
env.getCheckpointConfig().setCheckpointStorage(new FileSystemCheckpointStorage("hdfs://namenode:40010/flink/checkpoints")); 

注意：对于实际生产应用，我们一般会将 CheckpointStorage 配置为高可用的分布式文件系统 （HDFS，S3 等）。

3. 其他高级配置  

检查点还有很多可以配置的选项，可以通过获取检查点配置（CheckpointConfig）来进行设置。

CheckpointConfig checkpointConfig = env.getCheckpointConfig();

我们这里做一个简单的列举说明：

（1）检查点模式（CheckpointingMode）

设置检查点一致性的保证级别，有“精确一次”（exactly-once）和“至少一次”（at-least-once） 两个选项。默认级别为 exactly-once，而对于大多数低延迟的流处理程序，at-least-once 就够用 了，而且处理效率会更高。

（2）超时时间（checkpointTimeout）

用于指定检查点保存的超时时间，超时没完成就会被丢弃掉。传入一个长整型毫秒数作为 参数，表示超时时间。

（3）最小间隔时间（minPauseBetweenCheckpoints）

用于指定在上一个检查点完成之后，检查点协调器（checkpoint coordinator）最快等多久 可以出发保存下一个检查点的指令。这就意味着即使已经达到了周期触发的时间点，只要距离上一个检查点完成的间隔不够，就依然不能开启下一次检查点的保存。这就为正常处理数据留 下了充足的间隙。当指定这个参数时，maxConcurrentCheckpoints 的值强制为 1。

（4）最大并发检查点数量（maxConcurrentCheckpoints）

用于指定运行中的检查点最多可以有多少个。由于每个任务的处理进度不同，完全可能出 现后面的任务还没完成前一个检查点的保存、前面任务已经开始保存下一个检查点了。这个参 数就是限制同时进行的最大数量。

如果前面设置了 minPauseBetweenCheckpoints，则 maxConcurrentCheckpoints 这个参数就 不起作用了。

（5）开启外部持久化存储（enableExternalizedCheckpoints）

用于开启检查点的外部持久化，而且默认在作业失败的时候不会自动清理，如果想释放空 间需要自己手工清理。里面传入的参数 ExternalizedCheckpointCleanup 指定了当作业取消的时 候外部的检查点该如何清理。

⚫ DELETE_ON_CANCELLATION：在作业取消的时候会自动删除外部检查点，但是如 果是作业失败退出，则会保留检查点。

⚫ RETAIN_ON_CANCELLATION：作业取消的时候也会保留外部检查点。

（6）检查点异常时是否让整个任务失败（failOnCheckpointingErrors）

用于指定在检查点发生异常的时候，是否应该让任务直接失败退出。默认为 true，如果设置为 false，则任务会丢弃掉检查点然后继续运行。

（7）不对齐检查点（enableUnalignedCheckpoints）

不再执行检查点的分界线对齐操作，启用之后可以大大减少产生背压时的检查点保存时间。这个设置要求检查点模式（CheckpointingMode）必须为 exctly-once，并且并发的检查点 个数为 1。

StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment(); 
 
// 启用检查点，间隔时间 1 秒 
env.enableCheckpointing(1000); 
CheckpointConfig checkpointConfig = env.getCheckpointConfig(); 
// 设置精确一次模式 
checkpointConfig.setCheckpointingMode(CheckpointingMode.EXACTLY_ONCE); 
// 最小间隔时间 500 毫秒 
checkpointConfig.setMinPauseBetweenCheckpoints(500); 
// 超时时间 1 分钟 
checkpointConfig.setCheckpointTimeout(60000); 
// 同时只能有一个检查点 
checkpointConfig.setMaxConcurrentCheckpoints(1); 
// 开启检查点的外部持久化保存，作业取消后依然保留 
checkpointConfig.enableExternalizedCheckpoints( 
 ExternalizedCheckpointCleanup.RETAIN_ON_CANCELLATION); 
// 启用不对齐的检查点保存方式 
checkpointConfig.enableUnalignedCheckpoints(); 
// 设置检查点存储，可以直接传入一个 String，指定文件系统的路径 
checkpointConfig.setCheckpointStorage("hdfs://my/checkpoint/dir") 

10.1.5 保存点（Savepoint）

除了检查点（checkpoint）外，Flink 还提供了另一个非常独特的镜像保存功能——保存点 （Savepoint）。

从名称就可以看出，这也是一个存盘的备份，它的原理和算法与检查点完全相同，只是多了一些额外的元数据。事实上，保存点就是通过检查点的机制来创建流式作业状态的一致性镜像（consistent image）的。

保存点中的状态快照，是以算子ID和状态名称组织起来的，相当于一个键值对。从保存点启动应用程序时，Flink 会将保存点的状态数据重新分配给相应的算子任务。

1. 保存点的用途

保存点与检查点最大的区别，就是触发的时机。检查点是由 Flink 自动管理的，定期创建， 发生故障之后自动读取进行恢复，这是一个“自动存盘”的功能；而保存点不会自动创建，必须由用户明确地手动触发保存操作，所以就是“手动存盘”。

因此两者尽管原理一致，但用途就有所差别了：

检查点：主要用来做故障恢复，是容错机制的核心；

保存点：则更加灵活，可以用来做有计划的手动备份和恢复。

保存点可以当作一个强大的运维工具来使用。我们可以在需要的时候创建一个保存点，然后停止应用，做一些处理调整之后再从保存点重启。它适用的具体场景有：

⚫ 版本管理和归档存储

对重要的节点进行手动备份，设置为某一版本，归档（archive）存储应用程序的状态。

⚫ 更新 Flink 版本

目前 Flink 的底层架构已经非常稳定，所以当 Flink 版本升级时，程序本身一般是兼容的。 这时不需要重新执行所有的计算，只要创建一个保存点，停掉应用、升级 Flink 后，从保存点 重启就可以继续处理了。

⚫ 更新应用程序

我们不仅可以在应用程序不变的时候，更新 Flink 版本；还可以直接更新应用程序。前提 是程序必须是兼容的，也就是说更改之后的程序，状态的拓扑结构和数据类型都是不变的，这 样才能正常从之前的保存点去加载。

这个功能非常有用。我们可以及时修复应用程序中的逻辑 bug，更新之后接着继续处理； 也可以用于有不同业务逻辑的场景，比如 A/B 测试等等。

⚫ 调整并行度

如果应用运行的过程中，发现需要的资源不足或已经有了大量剩余，也可以通过从保存点重启的方式，将应用程序的并行度增大或减小。

⚫ 暂停应用程序

有时候我们不需要调整集群或者更新程序，只是单纯地希望把应用暂停、释放一些资源来处理更重要的应用程序。使用保存点就可以灵活实现应用的暂停和重启，可以对有限的集群资源做最好的优化配置。

需要注意的是，保存点能够在程序更改的时候依然兼容，前提是状态的拓扑结构和数据类型不变。我们知道保存点中状态都是以算子 ID-状态名称这样的 key-value 组织起来的，算子ID 可以在代码中直接调用 SingleOutputStreamOperator 的.uid()方法来进行指定：

DataStream stream = env 
 .addSource(new StatefulSource()) 
 .uid("source-id") 
 .map(new StatefulMapper()) 
 .uid("mapper-id") 
 .print(); 

对于没有设置 ID 的算子，Flink 默认会自动进行设置，所以在重新启动应用后可能会导致ID 不同而无法兼容以前的状态。所以为了方便后续的维护，强烈建议在程序中为每一个算子 手动指定 ID。

2. 使用保存点

保存点的使用非常简单，我们可以使用命令行工具来创建保存点，也可以从保存点恢复作 业。

（1）创建保存点

要在命令行中为运行的作业创建一个保存点镜像，只需要执行：

bin/flink savepoint :jobId [:targetDirectory]

这里 jobId 需要填充要做镜像保存的作业 ID，目标路径 targetDirectory 可选，表示保存点存储的路径。

对于保存点的默认路径，可以通过配置文件 flink-conf.yaml 中的 state.savepoints.dir 项来设定：

state.savepoints.dir: hdfs:///flink/savepoints 

当然对于单独的作业，我们也可以在程序代码中通过执行环境来设置：

env.setDefaultSavepointDir("hdfs:///flink/savepoints"); 

由于创建保存点一般都是希望更改环境之后重启，所以创建之后往往紧接着就是停掉作业的操作。除了对运行的作业创建保存点，我们也可以在停掉一个作业时直接创建保存点：

bin/flink stop --savepointPath [:targetDirectory] :jobId 

（2）从保存点重启应用

我们已经知道，提交启动一个 Flink 作业，使用的命令是 flink run；现在要从保存点重启 一个应用，其实本质是一样的：

bin/flink run -s :savepointPath [:runArgs] 

这里只要增加一个-s 参数，指定保存点的路径就可以了，其他启动时的参数还是完全一样 的。细心的读者可能还记得我们在第三章使用 web UI 进行作业提交时，可以填入的参数除了 入口类、并行度和运行参数，还有一个“Savepoint Path”，这就是从保存点启动应用的配置。