深入理解Flink ---- 系统内部消息传递的exactly once语义

最新推荐文章于 2025-05-04 12:55:52 发布
转载 最新推荐文章于 2025-05-04 12:55:52 发布 · 185 阅读 · 0 ·
CC 4.0 BY-SA版权
原文链接：http://www.cnblogs.com/tuowang/p/9022198.html
文章标签：

#大数据

本文介绍了分布式系统中的消息传递语义：AtMostOnce、AtLeastOnce和ExactlyOnce，并详细阐述了Flink如何利用AsynchronousBarrierSnapshotting算法实现ExactlyOnce语义，确保数据处理的一致性。

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

At Most once,At Least once和Exactly once

在分布式系统中，组成系统的各个计算机是独立的。这些计算机有可能fail。

一个sender发送一条message到receiver。根据receiver出现fail时sender如何处理fail，可以将message delivery分为三种语义:

 

At Most once: 对于一条message,receiver最多收到一次(0次或1次).

可以达成At Most Once的策略:

sender把message发送给receiver.无论receiver是否收到message,sender都不再重发message.

 

At Least once: 对于一条message,receiver最少收到一次(1次及以上).

可以达成At Least Once的策略:

sender把message发送给receiver.当receiver在规定时间内没有回复ACK或回复了error信息,那么sender重发这条message给receiver,直到sender收到receiver的ACK.

 

Exactly once: 对于一条message,receiver确保只收到一次

 

Flink的Exactly once模式

Flink实现Exactly once的策略: Flink会持续地对整个系统做snapshot,然后把global state(根据config文件设定)储存到master node或HDFS.当系统出现failure,Flink会停止数据处理,然后把系统恢复到最近的一次checkpoint.

什么是分布式系统的global state?

分布式系统由空间上分立的process和连接这些process的channel组成.

空间上分立的含义是,这些process不共享memory,而是通过在communication channel上进行的message pass来异步交流.

分布式系统的global state就是所有process,channel的local state的集合.

process的local state取决于the state of local memory and the history of its activity.

channel的local state是上游process发送进channel的message集减去下游process从channel接收的message的差集.

什么是一致性global state?

假设有两个银行账户A,B.A中初始有600美元,B中初始有200美元. SA, SB, CAB, CBA由A和B分别记录,组成了global state.

在t0时刻,A向B转账50美元;在t1时刻,B向A转账80美元.

如果SA, SB记录于(t0, t1), CAB, CBA记录于(t1, t2),那么global state = 550+200+50+80 = 880,比真实值多了$80. 这就是不一致性global state.

如果 SA, SB, CAB, CBA同属于一个时间区间,那么得到的global state就是一致性的.

Snapshot算法获得一致性global state的难点是什么?

分布式系统没有共享内存(globally shared memory)和全局时钟(global clock).

如果分布式系统有共享内存,那么可以从共享内存中直接获取整个分布式系统的snapshot,无需分别获得各个process,channel的local state再组合成global state.

如果分布式系统有global clock,那么所有的process能在同一时刻各自记录local state,这样就保证了state的一致性.

获得一致性global state的算法 ---- Chandy-Lamport算法

精髓:该算法在普通message中插入了control message – marker

前提:

1)       message的传输可能有delay,但一定会到达

2)       每两个process之间都有一条communication path(可能由多条channel组成)

3)       Channel是单向的FIFO

描述:

Marker sending rule for process Pi

(1)     Process Pi 记录自身state

(2)     Pi在记录自身state后,发送下一条message前,Pi向自己所有的outgoing channel发送marker

Marker receiving rule for process Pj on receiving a marker along channel C

如果Pj第一次接收到marker,那么

         把channel C的state记为空集

         执行marker sending rule

否则(并非第一次接收到marker)

         把记录自身state(或最近一次记录另一个channel的state)后,收到这个marker前的message集记为C的state

 

每个process会记录自身的state和它的incoming channel的state

图解:

A,B,C,D代表4个process.有向线段代表FIFO的channel.绿色圆形代表普通message,橙色矩形代表marker.蓝色的节点和线段代表已经记录state的process和channel

Process A启动snapshot算法,A执行marker sending rule(记录自身state,然后发送marker):

Process B接收到marker,执行marker receiving rule:将channel AB的state记为空集,然后记录自身state并向下发送marker:

 

Process C接收到marker, 执行marker receiving rule:将channel AC的state记为空集,然后记录自身state并向下发送marker:

 

Process D接收到来自于process B的marker, 执行marker receiving rule:将channel BD的state记为空集,然后记录自身state并向下发送marker:

 

 

Process D接收到来自于process C的marker, 执行marker receiving rule:这是process D第二次接收到marker,将channel CD的state记为{5},不会向下发送marker:

自此process A,B,C,D的local state和所有Channel的state都记录完毕. 将这些local state组合,所得到的就是global state

Flink的snapshot算法 ---- Asynchronous Barrier Snapshotting(ABS)

为了消去记录channel state这一步骤,process在接收到第一个barrier后不会马上做snapshot,

而是等待接受其他上游channel的barrier.

在等待期间,process会把barrier已到的channel的record放入input buffer.

当所有上游channel的barrier到齐后,process才记录自身state,之后向所有下游channel发送barrier.

因为先到的barrier会等待后到的barrier,所有所有barrier相当于同时到达process,

因此,该process的上游channel的state都是空集.这就避免了去记录channel的state

图解:

A是JobManager, B C是source,D是普通task.

JobManager发起一次snapshot:向所有source发送barrier.

每个Barrier先后到达各自的source.Source在收到barrier后记录自身state,然后向下游节点发送barrier

Barrier (from)B 到达process D,但不会进行snapshot

Barrier (from)B已经到达process D,

所以当来自于channel BD的record 6 7到达后,process D不会处理它们,而是将它们放入input buffer.

而Barrier (from)C尚未到达process D,所以当来自于channel CD的record 4到达后,process D会处理它.

Barrier C也到达process D.

这样,process D已经接收到了所有上游process的barrier.process D记录自身state,然后向下游节点发送barrier

ABS的at least once模式

当process接收到barrier后,会立刻做snapshot. Process会继续处理所有channel的record.后来的snapshot会覆盖之前的snapshot.

Record 6本不属于这次checkpoint,却包含在process D的local state中.

在recovery时,source认为record 6还没有被处理过,所以重发record 6. 这就导致stream中出现了两个record 6,造成了at least once.

 

这里的问题在于,当第二个barrier到达时,节点D再次对自身做了snapshot.

而在Chandy-Lamport的算法中,第二个barrier到达时,节点D应该对barrier来源的channel做snapshot.

 

对单一input channel的算子来说,没有Alignment这个概念.这些算子在at least once模式下也是呈现exactly once的行为.

 

转载于:https://www.cnblogs.com/tuowang/p/9022198.html

Flink 实时数据一致性与 Exactly-Once 语义保障实战
晴天彩虹雨的博客
05-10 651
本篇将围绕如何实现端到端的数据一致性、如何正确使用 Checkpoint、状态管理、Sink 的幂等性控制，以及与 Kafka / OLAP 系统的写入一致性设计进行详解
解读Flink中轻量级的异步快照机制--论文
lmalds的专栏
02-08 6980
Flink Snapshot ABS
Flink Exactly Once
技术大神之路
06-03 279
Flink Exactly Once Flink Exactly Once 语意是基于Chandy-Lamport这个算法的思想的改进版，引入了barrier，可以在不停止整个流处理系统的前提下，保存和恢复每个subtask的snapshot，让每个节点独立地做状态保存和恢复。 Chandy-Lamport 算法 Initiating a snapshot: 也就是开始创建 snapshot，可以由系统中的任意一个进程发起 Propagating a snapshot: 系统中其他进程开始逐个创建 sna
Flink -- Barrier
weixin_34194379的博客
06-05 300
CheckpointBarrierHandler 这个接口用于react从input channel过来的checkpoint barrier，这里可以通过不同的实现来，决定是简单的track barriers，还是要去真正的block inputs /** * The CheckpointBarrierHandler reacts to checkpoint barrier ...
Flink checkpoint实现算法的理论基础：Lightweight Asynchronous Snapshots for Distributed Dataflows
01-17 992
摘要： 分布式有状态的流式处理，让我们可以在云上部署和执行大规模持续计算，并实现了低延迟和高吞吐的目标。这种模式最基本的挑战之一是当发生了潜在故障，系统依旧提供正确的处理保证。当前的方法都依赖于周期性的全局快照，在故障时恢复数据。这些方法主要有两个缺点。第一，这些方法经常让整体计算停顿，影响数据摄入。第二，这些方法渴望于保存操作状态变化的所有记录。这种行为会导致产生超大量的快照信息，而这些快照信息...
轻松通关Flink第14讲：Flink Exactly-once 实现原理解析
sucaiwa的博客
03-27 517
由于强大的异步快照机制和两阶段提交，Flink 实现了“端到端的精确一次语义”，在特定的业务场景下十分重要，我们在进行业务开发需要语义保证时，要十分熟悉目前 Flink 支持的语义特性。这一课时的内容较为晦涩，建议你从源码中去看一下具体的实现。点击这里下载本课程源码。
flink-1.16.2下载安装包，flink-1.16.2-bin-scala-2.12.zip
02-29
- **容错机制**：Flink的Exactly-once语义在1.16.2中可能更加成熟，保证在故障后恢复时结果的准确性。 4. **安装与配置** - **解压**：首先，需要将`flink-1.16.2-bin-scala_2.12.zip`文件解压缩到本地目录。 - ...
Apache Flink 如何保证 Exactly-Once 语义
06-12 1312
Apache Flink 通过状态一致性检查点和 Two-Phase Commit 协议来确保 Exactly-Once 语义。这些机制确保了数据在分布式系统中的一致性和准确性，从而提高了大数据处理的可靠性和准确性。在实际应用中，我们可以根据具体需求配置 Flink 的检查点策略和外部存储系统的写入策略，以实现更好的性能和可靠性。
Flink Exactly-Once语义实现原理：大数据精准处理
最新发布
AI天才研究院
05-04 786
在实时流处理场景中，数据以无限流的形式持续产生，系统需要在分布式、高并发、故障频发的环境下保证数据处理的准确性。Flink的Exactly-Once语义承诺每个输入事件仅会被处理一次并产生唯一确定的结果，这对于金融交易、实时对账、物联网监控等对数据准确性要求极高的场景至关重要。本文将深入解析Flink实现Exactly-Once语义的核心技术，包括分布式快照（Checkpoint）机制水印（Watermark）事件时间处理。
flink-1.10.0-bin-scala_2.11.tgz
05-05
4. **Exactly-once语义**：Flink提供了严格的Exactly-once语义，即使在系统故障或异常情况下，也能确保结果的一致性。这得益于其检查点（Checkpoints）和保存点（Savepoints）机制。 5. **Connectors与Formats**：...
Chandy-Lamport算法 Barrier的传递
Wai0210的博客
05-11 361
JM中的CheckpointCoordinator协调器会向所有的source节点 触发一个Checkpoint 然后SourceTask 会在数据流中安插CheckPoint barrier source收到barrier后 会把source中的状态保存到hdfs(持久化存储) 然后barrier向下游传递 下游的Task(任何一个算子)只要收到barrier 会把自己的状态保存到hdfs(持久化存储) 当task完成Checkpoint后会通知协调器 并且把Checkpoint地址交给协调器 谁收到..
Flink中的Exactly-Once语义是什么？请解释其作用和实现原理。
jakelihua
09-10 509
键控状态是根据输入数据的键进行分区的状态，而操作符状态是与输入数据无关的状态。Flink将所有状态都保存在可靠的分布式存储系统中，如分布式文件系统或分布式数据库，以便在故障恢复时能够恢复到一致的状态。这样，即使在发生故障时，Flink也可以使用最近的检查点来恢复状态，并确保数据处理从故障点继续进行。精确的状态恢复：当Flink从故障中恢复时，它会使用最近的检查点来恢复状态，并从检查点之后的数据开始重新处理。为了确保数据的精确一次性处理，Flink会在处理过程中使用全局唯一的标识符来跟踪每个事件的处理状态。
Apache Flink ABS机制与原理分析
860MHz的专栏
06-11 990
1. 简介 分布式有状态的流处理支持在云端部署和执行大规模连续地计算，同时可以应对低延迟和高吞吐量场景。 这一模式最大的挑战之一是在系统可能失败的情况下提供数据可靠性保证。 现有方法依赖于可用于故障恢复的周期性全局状态快照。 此类方法有两个主要缺点：首先，它们通常会阻塞计算；其次，它们通常会保存传输中的所有记录和操作状态，这导致更多的快照数据。 而异步屏障快照（ABS）是一种适用于现代流处理引擎的...
Memory barrier（内存屏障）
yangjinkui的博客
08-03 721
理解 Memory barrier（内存屏障） 发布于 2014 年 04 月 21 日2014 年 05 月 15 日 作者 name5566 参考文献列表： http://en.wikipedia.org/wiki/Memory_barrier http://en.wikipedia.org/wiki/Out-of-order_execution https://www.kernel.
解读Flink中轻量级的异步快照机制--Flink 1.2 源码
lmalds的专栏
02-09 3565
Flink ABS Barrier
Flink流计算编程--状态与检查点
lmalds的专栏
07-21 1万+
Flink 流计算 快照 状态
【Flink实战系列】Flink 是如何实现 exactly-once 语义的
JasonLee实时计算
01-12 9692
Flink跟其他的流计算引擎相比,最突出或者做的最好的就是状态的管理.什么是状态呢?比如我们在平时的开发中,需要对数据进行count,sum,max等操作,这些中间的结果(即是状态)是需要保存的,因为要不断的更新,这些值或者变量就可以理解为是一种状态,拿读取kafka为例,我们需要记录数据读取的位置(即是偏移量),并保存offest,这时offest也可以理解为是一种状态. Flink是怎么保证...
ARM ACE协议学习（一）
热门推荐
崖野苦乐的博客
04-19 2万+
资料来源于ARM AXI4_specification ACE为AXI缓存扩展接口 ACE协议特点： 1、正确的跨缓存共享（CACHEs） 2、具有不同特征的器件交互 3、最大利用缓存数据 4、高性能低功耗之间的选择 ACE协议提供了系统级一致性框架，系统级设计包括 1、一致性存储范围 2、具有一致性扩展的存储系统器件 3、系统器件之间交互的软件模型 ACE协议实现通过 1、五个状态缓存模型，指明...
Flink 原理与实现：Checkpoint
GatsbyNewton
12-07 1789
本文尝试用图形化语言将抽象的 Checkpoint 具象化，阐述 Naive Consistent Checkpoint、Flink Checkpoint、Failure Recovery Mechanism、以及Performance of Checkpointing。
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 在分布式环境下实现了**状态一致性**和**端到端数据精确处理**，成为流处理领域的核心优势之一。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值