Flink 解析（四）：恢复机制

Stray_Lambs

已于 2023-12-18 18:14:13 修改

阅读量6k

点赞数 1

分类专栏： Flink 大数据文章标签： flink java

于 2021-12-14 18:40:42 首次发布

本文链接：https://blog.youkuaiyun.com/Stray_Lambs/article/details/121772462

版权

本文深入探讨了Flink的恢复机制，重点介绍了Checkpoint和Savepoint的概念及其作用。Checkpoint是全局性的状态快照，用于在Job失败时恢复；Savepoint则是保存特定时刻的集群状态，便于升级或迁移。文章还讨论了检查点协调器、 Barrier对齐和精准一次性(exactly once)语义，以及自动和手动恢复机制。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

Flink恢复机制

任何一个框架都存在出错的可能，所以都会有自己的一套恢复机制，例如Spark是采用血缘关系从头开始执行，如果有checkpoint就从checkpoint开始执行。Flink主要是根据每一个operator的状态以及全局的一个快照进行一个错误的恢复。

前提条件是Flink的checkpoint机制会与持久化存储进行交互，读写流与状态。

那么就需要：

一个能够回放一段时间内数据的持久化数据源，例如持久化消息队列（例如 Apache Kafka、RabbitMQ、 Amazon Kinesis、 Google PubSub 等）或文件系统（例如 HDFS、 S3、 GFS、 NFS、 Ceph 等）。
存放状态的持久化存储，通常为分布式文件系统（比如 HDFS、 S3、 GFS、 NFS、 Ceph 等）。

Checkpoint是什么

要了解Flink的恢复机制，首先我们需要了解，什么是Checkpoint。Checkpoint是Flink的检查点，是根据配置文件周期性基于Stream中各个Operator的状态而产生的全局性的SnapShot快照。然后定期持久化的存储到一些外设中，一旦Flink程序出现崩溃状态，则可以通过选择这些SnapShot快照进行快速恢复，从而修正因故障所产生的程序数据中断问题。其中，Flink的CheckPoint机制原理主要是来源于“Chandy-Lamport algorithm”。

这里简单介绍一下这个算法，首先这个算法的目标就是为了保证产生的快照必须具有一致性，并且不能stop the world，即不能影响程序的正常执行。其中分为三个阶段，初始化快照、扩散快照与完成快照。具体的详情就需要大家去看看其他文献了，这里就不多赘述了。

这里顺便区分一个概念，就是State与Checkpoint的关系。

State一般指的是一个具体的Task/Operator的状态(operator的状态表示一些算子在运行的过程中会产生的一些中间结果)。而State的数据默认是存储在了Java的堆内存/TaskManage的节点内存中，并且State可以被记录，在失败中可以用于恢复数据。有点局部状态的感觉。

Checkpoint有点类似与全局状态的感觉。表示的是一个FlinkJob在某个特定的时刻的一份全局快照，即保存了所有的Task/Operator的状态。可以理解为将所有的某个时刻的State持久化存储到外设中。

Savepoint保存点

Savepoint是基于Flink检查点机制的应用完整快照备份机制。主要是用来保存某个集群的某个时刻的状态，使得集群从保存的状态恢复回来。一般工程上用于应用升级、集群迁移、Flink版本更新、A/B测试等等。保存点可以理解为是一个Map(算子ID -> State)，其中的算子是有状态的算子。

由于一两句难以说明sp与cp的区别，我直接上个链接……

Savepoints | Apache Flink