Flink的Exactly-Once系列之两阶段提交实现分析

最新推荐文章于 2025-11-25 14:07:10 发布

后端架构魔术骑士

最新推荐文章于 2025-11-25 14:07:10 发布

阅读量110

点赞数 1

CC 4.0 BY-SA版权

文章标签： flink 大数据

本文链接：https://blog.youkuaiyun.com/ByteHackerX/article/details/132633501

大数据专栏收录该内容

122 篇文章 ¥59.90 ¥99.00

订阅专栏

本文深入探讨Flink如何通过两阶段提交（Two-Phase Commit）实现Exactly-Once语义，保证大数据处理的准确性和一致性。详细解析了Flink中的JobManager和TaskManagers的角色，以及源代码中涉及的事务管理和状态恢复过程。

Flink的Exactly-Once系列之两阶段提交实现分析

在大数据处理中，Exactly-Once语义是一种关键的需求。它确保了处理结果的准确性和一致性，无论在面对故障还是重启等情况下。Flink作为一个流式计算框架，提供了Exactly-Once语义的支持，并采用了两阶段提交（Two-Phase Commit）来实现此功能。

两阶段提交是一种常用的分布式事务协议，它通过使用协调者和参与者来保证事务的原子性和一致性。在Flink中，协调者是JobManager，而参与者是TaskManagers。下面我们将详细介绍Flink中Exactly-Once语义的两阶段提交实现方式。

首先，让我们看一下Flink的源代码实现。

public class TwoPhaseCommitSinkFunction<T, Txn>

了解本专栏

订阅专栏解锁全文

确定要放弃本次机会？

福利倒计时

: :

立减 ¥

普通VIP年卡可用

立即使用

后端架构魔术骑士

关注关注

1
点赞
踩
1

收藏

觉得还不错? 一键收藏
0
评论
分享

复制链接

分享到 QQ

分享到新浪微博

扫一扫
举报

举报

专栏目录

订阅专栏

Flink Exactly-once实现原理解析

微信搜：import_bigdata，大数据领域硬核原创作者

01-17

999

声明：本系列博客为原创，最先发表在拉勾教育，其中一部分为免费阅读部分。被读者各种搬运至各大网站。所有其他的来源均为抄袭。《2021年最新版大数据面试题全面开启更新》 Flink Exactly-once实现原理解析 Flink的“精准一次”处理语意是，Flink提供了一个强大的语义保证，也就是说在任何情况下都能保证数据对应用生产的效果只有一次，不会多也不会少。 Flink是如何实现“端到端的精确一次处理”语义的呢？背景通常情况下，流式计算系统都会为用户提供数据处理的可靠模式功能，用来表明在

Flink两阶段提交

热门推荐

lisenyeahyeah的博客

05-17

1万+

文章目录两阶段提交两阶段提交何为EXACTLY_ONCE？ EXACTLY_ONCE简称EOS，每条输入消息只会影响最终结果一次，注意这里是影响一次，而非处理一次，Flink一直宣称自己支持EOS，实际上主要是对于Flink应用内部来说的，对于外部系统(端到端)则有比较强的限制 1.外部系统写入支持幂等性 2.外部系统支持以事务的方式写入什么是两阶段提交？预提交+实际提交 flink里将两阶...

参与评论您还未登录，请先登录后发表或查看评论

Flink实现两阶段提交协议原理介绍

道可道非常道

04-01

1111

通过 Checkpoint 机制和两阶段提交，Flink 实现了 Exactly-Once 语义，保证了作业的状态一致性。这种机制不仅可以处理单个节点的故障，还可以应对整个作业的故障，从而确保数据处理的正确性和可靠性。

Doris UNIQUE 表使用 Flink Doris Connector两阶段提交数据未写入分析

qq_26921975的博客

10-17

1248

因此对于 UNIQUE 模型来讲，没必要去设置 'sink.properties.two_phase_commit' = 'true'，因为一旦设置这个，在StreamLoad 导入时，就会将 two_phase_commit 设置到 http 的 header 中，Doris 就会认为开启了两阶段提交，但是 enable2PC 又为 false，就导致了事务没有提交，数据没有正在写入。顺便吐槽下 Doris 的官方文档，需要完善一下。

flink二阶段提交mysql_flink-----实时项目---day07-----1.Flink的checkpoint原理分析 2. 自定义两阶段提交sink（MySQL） 3 将数据写入Hba...

weixin_32968105的博客

01-20

651

1.Flink中exactly once实现原理分析生产者从kafka拉取数据以及消费者往kafka写数据都需要保证exactly once。目前flink中支持exactly once的source不多，有kafka source；能实现exactly once的sink也不多，如kafka sink、streamingFileSink，其都要开启checkpoint才能实现exactly on...

flink的mysql两阶段提交_flink exactly-once系列之两阶段提交实现分析

weixin_32751907的博客

03-06

432

flink exactly-once系列目录：一、[两阶段提交概述](http://mp.weixin.qq.com/s?__biz=MzU5MTc1NDUyOA==&mid=2247483818&idx=1&sn=8c7bf4d00e81d7635bfa26b78a78ebba&chksm=fe2b65e5c95cecf349d9819fe6c998359cb9a...

Flink Exactly-Once 语义

csdn_tom_168的博客

07-19

1141

Flink实现Exactly-Once语义的核心机制包括分布式快照和两阶段提交。分布式快照通过Barrier机制捕获作业全局一致状态，确保故障恢复后状态准确。两阶段提交协议保证Sink到外部系统的原子性写入，要求外部系统支持事务或幂等操作。关键条件是Source可重放、State持久化、Sink支持事务。典型实现如Kafka事务写入和JDBC幂等设计。故障时从最近Checkpoint恢复，重置偏移量并回滚未提交事务。通过异步Checkpoint、Barrier对齐优化等提升性能。相比At-Least-Onc

详解flink exactly-once和两阶段提交

weixin_51981189的博客

01-09

1899

Source 端的精准一次处理比较简单，毕竟数据是落到 Flink 中，所以 Flink 只需要保存消费数据的偏移量即可，如消费 Kafka 中的数据，Flink 将 Kafka Consumer 作为 Source，可以将偏移量保存下来，如果后续任务出现了故障，恢复的时候可以由连接器重置偏移量，重新消费数据，保证一致性。在 Flink 1.4 版本之前，精准一次处理只限于 Flink 应用内，也就是所有的 Operator 完全由 Flink 状态保存并管理的才能实现精确一次处理。

Flink Exactly-Once语义实现原理：大数据精准处理

AI天才研究院

05-04

894

在实时流处理场景中，数据以无限流的形式持续产生，系统需要在分布式、高并发、故障频发的环境下保证数据处理的准确性。Flink的Exactly-Once语义承诺每个输入事件仅会被处理一次并产生唯一确定的结果，这对于金融交易、实时对账、物联网监控等对数据准确性要求极高的场景至关重要。本文将深入解析Flink实现Exactly-Once语义的核心技术，包括分布式快照（Checkpoint）机制水印（Watermark）事件时间处理。

Flink Exactly-once 实现原理解析

qianyulin

10-24

1951

通常情况下，流式计算系统都会为用户提供指定数据处理的可靠模式功能，用来表明在实际生产运行中会对数据处理做哪些保障，Flink提供了Exactly-once语义来保障我们的流任务数据处理的精准一致性

95-241-102-源码-Flink语义-Flink的exectly-once系列之两阶段提交实现分析

九师兄

07-01

817

2.概述在上一章中介绍了两阶段提交的基本思路以及如何根据checkpoint机制来实现两阶段提交思路，flink给出来两阶段提交抽象实现TwoPhaseCommitSinkFunction与具体实现FlinkKafkaProducer011。 3.TwoPhaseCommitSinkFunction TwoPhaseCommitSinkFunction是一个抽象类，继承RichSinkFunction，实现CheckpointedFunction与CheckpointListener接口。抽象.

【大数据面试题】002 Flink 如何实现 Exactly-Once 语义

Jweilai

02-04

1190

最后，在数据消费端，需要确保消费者能够支持“事务性”提交，比如使用支持事务的数据库（如 MySQL）进行数据写入。这样，在发生故障时，Flink 可以回滚未完成的事务，并重新执行已提交的事务，从而保证数据的一致性和准确性。尽管在程序正常运行、资源充足的情况下实现 Exactly-Once 语义并不难，但实际生产环境中存在各种复杂情况和突发状况，因此为了可靠地实现 Exactly-Once，需要以下容错机制。这样，如果程序重启，可以准确地从未被消费的第一条数据开始读取，既不会多读也不会少读。

Flink CDC系列之：Doris 模式工具类DorisSchemaUtils

zhengzaifeidelushang的博客

11-24

Flink CDC系列之：Doris 模式工具类DorisSchemaUtils

在 Kubernetes 上跑 Flink CDCSession 模式 + Operator 模式实战指南

最新发布

hello.reader

11-25

429

Flink在Kubernetes上的部署与CDC实时同步实现本文详细介绍了Flink在Kubernetes环境中的两种部署模式及CDC实时数据同步的实现方案。主要内容包括：部署架构：原生Kubernetes集成：JobManager/TaskManager以Pod形式运行，支持动态资源管理 Kubernetes Operator模式：通过CRD管理Flink集群生命周期 Session模式实现：使用kubernetes-session.sh脚本创建Session集群配置REST访问和Flin

在 Flink Standalone 集群上运行 Flink CDC从下载到跑起一个 MySQL→Doris 同步任务

hello.reader

11-25

932

本文介绍了如何在Flink Standalone模式下快速搭建CDC数据同步环境，实现MySQL到Doris的实时数据同步。主要内容包括：1）Flink Standalone集群的安装部署；2）Flink CDC独立包的配置方法；3）通过YAML文件定义MySQL到Doris的同步流水线；4）任务提交和监控方法。文章还提供了生产环境实践建议，如server-id管理、权限配置、时区设置等，帮助用户快速构建稳定可靠的CDC数据同步系统。

在 YARN 上跑 Flink CDC从 Session 到 Yarn Application 的完整实践

hello.reader

11-25

1179

本文介绍了Flink CDC在YARN集群上的两种运行模式：Yarn Session模式和Yarn Application模式。Session模式适合开发调试，先启动长期运行的Flink集群再提交作业；Application模式更适合生产环境，每个作业独立启动专属集群，提供更好的资源隔离。文章详细讲解了环境准备步骤，包括YARN集群验证、Flink安装配置和Hadoop类路径设置。针对MySQL到Doris的数据同步场景，提供了配置文件示例和两种模式的作业

Flink Checkpoint 和 Spark Checkpoint 的区别

好记性不如烂笔头

11-23

931

更像一个“它主要目的是，避免因链路过长导致的性能问题或 StackOverflowError。它是一个** coarse-grained（粗粒度）** 的、的、的容错机制。：是一个“它是 Flink，用于在发生故障时，将整个分布式数据流状态恢复到一致性的检查点，实现或 At-Least-Once 语义。它是一个的、的、的容错机制。简单来说，Spark Checkpoint 是为了解决 RDD 带来的内部问题，而 Flink Checkpoint 是对外提供容错保证的核心特性。

Flink CDC 用 PolarDB-X CDC 实时同步数据到 Elasticsearch

Loving_enjoy的博客

11-23

146

在实际应用中，记得根据你的具体业务需求调整配置和优化策略。PolarDB-X 的 **CDC（Change Data Capture）** 组件，也称为**日志节点**，是 PolarDB-X 实例的一个可选子集群。而 **PolarDB-X** 作为阿里云开发的分布式数据库，其 **CDC 组件**能够输出全局 Binlog，为数据同步提供了稳定可靠的数据源。- **数据一致性**：PolarDB-X 的全局 Binlog 保证了分布式环境下数据变更的**全局一致性**，为数据同步提供了可靠基础。

轻量级 CI/CD 实战（四）：本地开发钉钉告警 → 自动部署云服务器 Kafka 消费者容器

m0_74234518的博客

11-24

934

摘要：轻量级 CI/CD 实现 Kafka 消费者容器自动化部署与钉钉告警本文介绍如何在现有轻量级 CI/CD 流程中，为 Kafka 消费者容器新增钉钉告警功能并实现自动化部署。通过改造 Git Hooks 的 post-receive 脚本，实现代码推送后自动构建 Docker 镜像、替换运行中的容器。关键点包括：1) 本地开发时通过环境变量管理钉钉 Token；2) 使用异步线程发送告警避免阻塞主流程；3) 服务器端通过安全文件存储敏感信息；4) 全自动化部署流程覆盖镜像构建、容器替换等环节。整个方

八张图搞懂Flink的Exactly-once

01-08

### Flink Exactly-Once Semantics Explained In the context of stream processing, ensuring that each record is processed only once (exactly-once) without any loss or duplication becomes critical for applications requiring high accuracy and reliability. For this purpose, Apache Flink implements sophisticated mechanisms to guarantee exactly-once delivery semantics. #### Importance of Exactly-Once Processing Exactly-once processing ensures every message is consumed precisely one time by downstream systems, preventing both data loss and duplicate records[^3]. This level of assurance is particularly important when dealing with financial transactions, billing information, or other scenarios where even a single error can lead to significant issues. #### Implementation Mechanisms To achieve exactly-once guarantees, Flink employs several key technologies: 1. **Checkpointing**: Periodic snapshots are taken across all operators within a job graph at consistent points in time. These checkpoints serve as recovery states which allow jobs to resume from these saved positions upon failure. 2. **Two-phase commit protocol**: When interacting with external systems like databases or messaging queues through sinks, Flink uses an extended version of the two-phase commit transaction mechanism. During checkpoint creation, pre-commit actions prepare changes; after successful completion of the checkpoint process, global commits finalize those operations[^4]. ```mermaid graph LR; A[Start Transaction] --> B{Prepare Changes}; B --> C(Pre-Commit); C --> D{All Pre-commits Succeed?}; D -->|Yes| E(Global Commit); D -->|No| F(Abort); ``` This diagram illustrates how the two-phase commit works during sink operations. Each operator prepares its part before confirming globally whether everything has been successfully prepared. Only then does it proceed with committing or aborting based on consensus among participants. #### Barrier Insertion & Propagation For maintaining consistency between different parts of computation while taking periodic snapshots, barriers play a crucial role. They act as synchronization markers inserted into streams periodically according to configured intervals. As they propagate along with events throughout the topology, they ensure that no new elements enter until previous ones have completed their respective stages up till the barrier point. ```mermaid sequenceDiagram participant Source participant OperatorA participant OperatorB Note over Source: Time advances... Source->>OperatorA: Data Element 1 Source->>OperatorA: Checkpoint Barrier X Source->>OperatorA: Data Element 2 OperatorA->>OperatorB: Forwarded Elements + Barrier X Note right of OperatorB: Process pending items\nbefore handling next element post-barrier ``` The sequence above shows how barriers travel alongside regular data flow but enforce order so that computations remain synchronized despite asynchronous nature inherent in distributed environments. --related questions-- 1. What challenges arise when implementing exactly-once semantics in real-world applications? 2. How do checkpointing frequencies impact performance versus fault tolerance trade-offs? 3. Can you explain what happens if some nodes fail midway through a two-phase commit operation? 4. Are there alternative methods besides using barriers for achieving similar levels of consistency? 5. In practice, under what circumstances might at-least-once be preferred over exactly-once semantics?