Flink的分布式快照（检查点算法）原理--基于Chandy-Lamport算法

最新推荐文章于 2025-08-27 13:54:45 发布
原创 最新推荐文章于 2025-08-27 13:54:45 发布 · 置顶 · 2.8k 阅读 · 7 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#flink

本文深入探讨Flink的恢复机制——一致性检查点，详细解释其核心算法：基于Chandy-Lamport算法的分布式快照。文章通过图解方式阐述检查点在Flink任务流程中的实现原理，包括CheckpointBarrier的作用、检查点的两种实现方式及其优化过程。

Flink的恢复机制的核心就是应用状态的一致性检查点，有状态流的一致性检查点，其实就是所有状态在某个时间点的一份快照拷贝，而这个时间点应该是所有任务都恰好处理完同一个输入数据。
**

Flink使用的检查点算法是分布式快照算法（基于Chandy-Lamport算法的分布式快照）

**
检查点的两种实现：
（1）检查点算法的简单实现–暂停应用，保存状态到检查点，在重新恢复应用
（2）Flink基于检查点算法的优化实现–基于Chandy-Lamport算法的分布式快照，将检查点的保存和数据分开处理，不需要暂停整个应用，这里引入状态后端的概念。
以下介绍flink的检查点算法：
首先介绍一个概念：Checkpoint Barrier，记住他的作用哦
在这里插入图片描述
图解检查点算法在flink任务流程中的实现原理：
1.两条流使用2个source来读取数据
在这里插入图片描述

2.jobmanager会向每个source任务发送一个带有检查点id的消息，启动检查点（如图中ID=2）
jobmanager启动一个id为2的检查点
3.source将读取的偏移量状态写入检查点id为2的状态后端中，并发送一个barrier（检查点屏障–对应的id也为2）；
状态后端保存完成会通知source任务，s

最低0.47元/天 解锁文章
【Flink】分布式快照算法—— Chandy-Lamport 算法
九师兄
10-03 1992
https://blog.csdn.net/hxcaifly/article/details/87872150
用一个通俗易懂具体形象的例子讲解一下 Chandy-Lamport 算法原理
AI天才研究院
12-25 464
其他人收到消息后，会比较自己手表的时间和消息中的时间，选择较大的那个作为自己的新时间，并将该值传递给其他人。当接收到消息的人收到消息后，会比较自己的逻辑时钟值和消息中的值，选择较大的那个作为自己的新逻辑时钟值，并将该值传递给其他人。：每个人在看到房间门上的标记后，都会记录下自己手里的礼物数量，并且在他们进入新的房间时，也会做同样的事情。：你决定开始记录，于是你拿出一个笔记本，记录下你自己手里的礼物数量，然后你给每个房间的门口贴上一个标记，表示“从现在开始，进出这个房间的人都要告诉我他们手里的礼物数量”。
Flink分布式快照的原理是什么？
mischen520的博客
07-11 1749
Flink的容错机制的核心部分是制作分布式数据流和操作算子状态的一致性快照。 这些快照充当一致性checkpoint，系统可以在发生故障时回滚。 Flink用于制作这些快照的机制在“分布式数据流的轻量级异步快照”中进行了描述。 它受到分布式快照的标准Chandy-Lamport算法的启发，专门针对Flink的执行模型而定制。 barriers在数据流源处被注入并行数据流中。快照n的barriers被插入的位置（我们称之为Sn）是快照所包含的数据在数据源中最大位置。 例如，在Apache Kaf.
Flink CDC高级特性：Exactly-Once与分布式快照
最新发布
gitblog_00317的博客
08-27 836
Flink CDC通过创新的增量快照算法和分布式快照机制，实现了Exactly-Once语义的高效数据同步。本文深入解析了增量快照算法的实现原理、分布式扫描与CDC事件无缝切换机制、Exactly-Once语义保障机制以及故障恢复与数据一致性保证策略，全面展现了Flink CDC在企业级数据集成中的核心技术优势。 ## 增量快照算法实现原理与优势分析 Flink CDC 的增量快照算法是其实...
一文读懂之flink分布式快照checkpoint
吴成伟的博客
03-01 1053
Flink checkpoint 什么是Flink? Apache Flink is a framework and distributed processing engine for stateful computations over unbounded and bounded data streams. Flink has been designed to run in all common cluster environments, perform computations at in-memory
Flink中基于Chandy-Lamport算法的分布式快照实现详解
木南曌的博客
05-14 936
Apache Flink利用了一种基于Chandy-Lamport分布式快照算法的变体——异步屏障快照（Asynchronous Barrier Snapshotting, ABS）来实现其强大的容错机制。Chandy-Lamport算法最初由K.M. Chandy和Leslie Lamport于1985年提出，是一种用于分布式系统中创建全局一致状态快照的算法。下面将深入介绍Flink如何采用并改进这一算法以适应流处理的需求。
Flink 检查点（checkpoint）
hyunbar的博客
03-25 6696
Flink具体如何保证exactly-once呢? 它使用一种被称为"检查点"（checkpoint）的特性，在出现故障时将系统重置回正确状态。下面通过简单的类比来解释检查点的作用。 假设你和两位朋友正在数项链上有多少颗珠子，如下图所示。你捏住珠子，边数边拨，每拨过一颗珠子就给总数加一。你的朋友也这样数他们手中的珠子。当你分神忘记数到哪里时，怎么办呢? 如果项链上有很多珠子，你显然不想从...
Flink-容错机制 | 一致性检查点 | 检查点到恢复状态过程 | Flink检查点算法(Chandy-Lamport) | 算法操作解析 | 保存点简介
SmallScorpion
05-29 2065
一致性检查点（Checkpoints） Flink 故障恢复机制的核心，就是应用状态的一致性检查点 有状态流应用的一致检查点，其实就是所有任务的状态，在某个时间点的一份拷贝（一份快照）；这个时间点，应该是所有任务都恰好处理完一个相同的输入数据的时候(如5这个数据虽然进了奇数流但是偶数流也应该做快照，因为属于同一个相同数据，只是没有被他处理) 在JobManager中也有个Chechpoint的指针，指向了仓库的状态快照的一个拓扑图，为以后的数据故障恢复做准备 从检查点恢复状态 在执行流应
Chandy-Lamport分布式快照学习记录和Flink与实现分布式快照的机制
小凯的博客
11-13 875
Snapshot Algorithm 分布式快照算法是拿来干嘛的？ 在缺乏全局时钟或者全局时钟不可靠的分布式系统确定全局状态 A snapshot algorithm is used to create a consistent snapshot of the global state of a distributed system. Due to the lack of globally sh...
【Flink】检查点算法实现原理之检查点分界线
weixin_43923463的博客
12-03 855
当接收到一个分界线2和数据4，数据4不能和数据8进行累加，分界线2之后的所有数据都不能进行累加，都需要缓存到sum even算子中，而橘色的检查点2之前的数据，都需要和数据8进行累加，这就是上面两句话的意思，同时也是检查点分界线名称的由来，其将数据流分隔开了。JobManager 会向 Source 任务针对每一个并行任务，都发送一条带有新检查点ID 消息的检查点分界线（三角形，当前检查点分界线id=2，此处的2与数据无关），通过这种方式让检查点分界线跟随着数据向下游流动，达到来启动检查点的目的。
Flink的检查点算法-Chandy-Lamport分布式快照算法
qq_34158117的博客
08-07 936
Flink的检查点算法 Flink检查点算法的正式名称是异步分界线快照(asynchronous barrier snapshotting)。该算法大致基于Chandy-Lamport分布式快照算法。 Flink检查点的核心作用是确保状态正确，即使遇到程序中断，也要正确。记住这一基本点之后，我们用一个例子来看检查点是如何运行的。Flink为用户提供了用来定义状态的工具。例如，以下这个Scala程序按照输入记录的第一个字段(一个字符串)进行分组并维护第二个字段的计数状态。 valstream:Dat..
【Flink原理和应用】：分布式快照算法—— Chandy-Lamport 算法
hxcaifly的博客
02-22 3267
引言 Spark 的 Structured Streaming 的 Continuous Processing Mode 的容错处理使用了分布式快照（Distributed Snapshot）算法 Chandy-Lamport 算法，那么分布式快照算法可以用来解决什么问题呢？ A snapshot algorithm is used to create a consistent snapshot...
一文搞懂 Flink 的 Exactly Once 和 At Least Once
http://www.54tianzhisheng.cn/
08-05 1737
本文由知识星球小伙伴 范瑞 投稿，原文地址：https://www.jianshu.com/p/8d6569361999本文主要为了让你搞懂 Flink 的 Exactl...
Flink的检查点（CheckPoint）算法
weixin_42051673的博客
09-23 1191
Flink检查点的核心作用是确保状态正确，即使遇到程序中断，也要正确。 flink的检查点算法用到了一种特殊的数据类型checkpoint barrier （检查点分割线），在checkpoint barrier到来之前的所有状态更改都会存到该分割线所属检查点中，而在checkpoint barrier到来后的数据会存到下一个检查点中 以下举例解析 val stream: DataStream[(String, Int)] = ... val counts: DataStream[(Strin..
flink checkpoint分布式快照原理实现
weixin_42611177的博客
01-03 233
Flink 的 checkpoint 分布式快照是一种用于记录 Flink 应用程序执行状态的机制。当 Flink 应用程序执行时，系统会定期创建 checkpoint。在 checkpoint 过程中，Flink 会将应用程序的执行状态(包括每个任务的状态和所有数据流的指针)写入分布式存储系统中。 当 Flink 应用程序因为故障或其他原因停止时，可以使用 checkpoint 恢复应用程序的执...
Chandy-Lamport分布式快照算法
Shyllin的博客
01-26 2499
文章目录Chandy-Lamport分布式快照算法Distributed SnapshotThe Chandy-Lamport AlgorithmExample Chandy-Lamport分布式快照算法 Distributed Snapshot 分布式快照：特定时间点记录下来的分布式系统的全局状态（global state）。 分布式快照主要用途：故障恢复（即检查点）、死锁检测、垃圾收集等。 将分布式系统抽象为一张有向图：顶点称为进程（process），边称为channel。下图就示出包含3个进程和4个c
Flink检查点的实现算法
weixin_43918355的博客
07-14 390
检查点分界线 FLink的检查点算法用到了一种称为分界线(barrier)的特殊数据形式, 用来把一条流上数据按照不同的检查点分开 分界线之前到来的数据导致的状态更改, 都会被包含在当前分界线所属的检查点中; 而基于分界线之后的数据导致的所有更改, 就会被包含在之后的检查点中 检查点运行过程 1, JobManager会向每个source任务发送一条带有新检查点ID的消息, 通过这种方式来启动检查点 (比如有两个source现在source-1处理到2了, source-2处理到3了, 这个时候sour
Flink 分布式快照的设计与存储
CodeHeroicX的博客
09-17 232
Apache Flink 是一个流式处理引擎，它提供了强大的快照机制，能够有效地将分布式数据流的状态保存到持久化存储中。检查点是一个全局一致的数据快照，它包含了所有参与计算的任务的状态信息。为了生成检查点，Flink 需要将数据流切分为不同的分区，并将每个分区的状态保存到不同的存储设备中。它通过协调任务之间的状态快照生成，并将快照保存到持久化存储设备中，以实现数据的恢复和保护。用户可以根据自己的需求选择适合的存储后端，并通过相应的配置和代码实现快照的生成和恢复。用户可以根据自己的需求选择合适的存储设备。
fifo算法_分布式快照算法: ChandyLamport 算法
weixin_39718083的博客
11-29 209
本文转载自：https://zhuanlan.zhihu.com/p/534821030. 引言Spark 的 Structured Streaming 的 Continuous Processing Mode 的容错处理使用了分布式快照(Distributed Snapshot)算法 Chandy-Lamport 算法，那么分布式快照算法可以用来解决什么问题呢？Asnapshot a...
Flink 是如何保证 Exactly-once 语义的
03-01
<think>嗯，用户问的是Flink如何保证Exactly-once语义。我需要先回忆一下Flink的相关知识。Exactly-once是流处理中非常重要的特性，确保每条数据只被处理一次，即使在故障恢复时也是如此。 首先，Flink的检查点机制应该是关键。检查点基于Chandy-Lamport算法，定期保存作业状态。每个检查点会插入barrier到数据流中，barrier将流分成不同的窗口，当所有任务都确认状态保存后，检查点才算完成。这样在故障恢复时，可以从最近的检查点重启，保证状态的一致性。 然后，可能需要提到状态后端，比如RocksDB，它支持异步快照，减少对处理性能的影响。不过状态后端具体是存储部分，可能和Exactly-once的实现关系不大，但检查点的持久化存储确实重要。 另外，两阶段提交协议（2PC）在Flink中的应用。比如在连接外部系统（如Kafka）时，Flink通过TwoPhaseCommitSinkFunction实现精确一次输出。这涉及到预提交和提交两个阶段，确保数据要么完全提交，要么回滚，避免部分写入。 还需要区分Exactly-once的不同层次：Flink内部的状态一致性，以及端到端的精确一次。内部通过检查点和恢复机制，而端到端需要外部系统的协同，比如支持事务的Sink。 可能用户需要具体的步骤或流程图说明。比如检查点的触发、barrier对齐、状态快照，故障恢复时的状态回滚和重放数据。这时候分步骤解释会更清晰。 还要注意不同版本的Flink是否有改进，比如在Aligned Checkpoint和Unaligned Checkpoint的区别，后者在反压严重时也能保证生成检查点，但可能会影响Exactly-once的保证吗？不过用户可能不需要这么深入，但可能需要简单提及。 另外，可能用户对Exactly-once和At-least-once的区别有疑惑，可以简要比较，但用户的问题主要关注Exactly-once的实现，所以重点应在Flink的机制。 总结下来，回答的结构应该是：先介绍Exactly-once的重要性，然后分检查点机制和两阶段提交，再讲内部和端到端的保证，可能最后举例说明，比如Kafka到Flink再到Kafka的案例。需要确保用中文，行内公式正确，结构清晰。</think>Flink 通过**分布式快照检查点（Checkpoint）**和**两阶段提交协议（2PC）**的结合实现端到端的 Exactly-once 语义。以下是其核心机制的分步解析： --- ### 一、Checkpoint 机制：保证内部状态一致性 1. **触发检查点** JobManager 周期性触发检查点（如每 10 秒），向 Source 节点插入**特殊标记（Barrier）**到数据流中，将数据流逻辑切分为窗口。 2. **Barrier 对齐** - 每个算子收到 Barrier 后暂停处理后续数据，**先缓存输入流的数据**。 - 当所有输入流的 Barrier 都到达时，算子将当前状态**异步持久化**到可靠存储（如 HDFS/S3）。 - 公式表示状态保存过程： $$ S_i = f(S_{i-1}, D_{window}) $$ 其中 $S_i$ 为第 $i$ 次检查点状态，$D_{window}$ 为当前窗口数据。 3. **恢复机制** 故障时，Flink 回滚到最近完整的检查点，从持久化状态重新处理后续数据，确保状态与数据流完全一致。 --- ### 二、端到端 Exactly-once：两阶段提交协议（2PC） 对于外部系统（如 Kafka、数据库），Flink 通过 **`TwoPhaseCommitSinkFunction`** 实现事务性写入： | 阶段 | 行为 | |---------------------|----------------------------------------------------------------------| | **1. 预提交（Pre-commit）** | Sink 将数据写入外部系统，但标记为**未提交**（如 Kafka 事务未提交）。 | | **2. 提交（Commit）** | 当 Checkpoint 完成时，JobManager 通知所有算子提交事务。 | | **回滚（Rollback）** | 若 Checkpoint 失败，事务自动回滚，外部系统丢弃未提交数据。 | --- ### 三、关键设计优化 1. **精确一次 vs 至少一次** - *Exactly-once*：通过 Barrier 对齐和事务提交确保一致性。 - *At-least-once*：Barrier 不对齐时可能重复处理数据。 2. **反压处理** - **Unaligned Checkpoint**（Flink 1.11+）：允许 Barrier 跨越缓存数据，避免反压导致检查点超时。 3. **端到端场景示例** ```text Kafka → Flink → Kafka └── Source 记录消费偏移量（状态） └── Sink 开启 Kafka 事务写入 └── Checkpoint 成功时提交偏移量和事务 ``` --- ### 四、适用场景 - **高一致性要求**：金融交易、计费系统。 - **高吞吐场景**：Checkpoint 间隔需权衡吞吐和恢复时间。 通过以上机制，Flink 在分布式环境下实现了**状态一致性**和**端到端数据精确处理**，成为流处理领域的核心优势之一。
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值