Exactly-once 只有一次的两个阶段提交 （Exactly-once two-phase commit）

最新推荐文章于 2022-10-13 11:49:11 发布
最新推荐文章于 2022-10-13 11:49:11 发布
阅读量256 收藏 1
点赞数 2
分类专栏： 大数据之Flink
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/weixin_52346735/article/details/114705868
版权
博客详细描述了Exactly-once的两阶段提交过程，从Data Source从Kafka读取数据开始，通过JobManager协调各个算子的checkpoint，确保状态在State Backend中的持久化。当所有状态保存完成后，JobManager接收到ack后通知Subtask提交事务。如果提交失败，将从State Backend恢复状态并重试。预提交的数据在JobManager发送最终提交指令时才完成事务，以防止因机器宕机导致的脏数据问题。
摘要由CSDN通过智能技术生成

在这里插入图片描述
在这里插入图片描述

在这里插入图片描述
在这里插入图片描述
Data Source 会先从 kafka 里面读取数据

JobManger 会向 Data Source 中 发起 Checkpoint 指令并同时向 S ource 发送 barrier （检查点分界线），

如果这个Source 有多个并行，那么每个Source 都会有一个 barrier
这个 barrier 会把 Data Source 中的状态保存起来持久化到 State Backend 中 ，

然后 barrier 会向下个算子Window 中传递，然后我们假如会在 Window 中做一些聚合运算，然后再把他当前的状态 保存起来，持久化到 staState Backend 中，

再继续传递给下一个算子 Sink 中 ，同样把它当前的状态保存起来，持久化到 State Backend 中，

等到所有算子都完成了 Checkpo

最低0.47元/天 解锁文章
flink实战--如何自定义具有Exactly-Once语义的sink（TwoPhaseCommitSinkFunction）
阿华田的博客
04-21 2386
Exactly-Once 语义 指的是每个输入的事件只影响最终结果一次。即使机器或软件出现故障，既没有重复数据，也不会丢数据。 Flink一次性语义实现原理 说到flink的Exactly-Once，要区分实现的范围。在 Flink 1.4.0 之前，Exactly-Once 语义仅限于 Flink 应用程序内部，并没有扩展到 Flink 数据处理...
Flink两阶段提交协议 + Kakfa事务 保证端到端唯一 /TwoPhaseCommitSinkFunction / Kafka的幂等性和事务
Top5软件工程硕士，先后在京东、字节从事多年Java后端开发、实时和离线大数据开发
02-22 4929
文章目录 Flink两阶段提交 1.EXACTLY_ONCE语义 2.Kafka的幂等性和事务 2.1 幂等性 2.2 事务 3.两阶段提交协议 4.TwoPhaseCommitSinkFunction 参考文献 Flink两阶段提交 1.EXACTLY_ONCE语义 EXACTLY_ONCE语义简称EOS，指的是每条输入消息只会影响最终结果一次，注意这里是影响一次，而非处理一次，Flink一直宣称自己支持EOS，实际上主要是对于Flink应用内部.
深入理解Flink ---- End-to-End Exactly-Once语义
weixin_30268921的博客
05-11 376
上一篇文章所述的Exactly-Once语义是针对Flink系统内部而言的. 那么Flink和外部系统(如Kafka)之间的消息传递如何做到exactly once呢? 问题所在: 如上图,当sink A已经往Kafka写入了数据,而sink B fail. 根据Flink的exactly once保证,系统会回滚到最近的checkpoint, 但是sink A已经把数据写入...
flink 通过两阶段提交实现exactly-once
xiaopeigen的专栏
08-31 717
一、flink Exactly-Once与At-Least-Once 关于消息的消费、处理语义可以分为三类： 1. at most once : 至多一次，表示一条消息不管后续处理成功与否只会被消费处理一次，那么就存在数据丢失可能 2\. exactly once : 精确一次，表示一条消息从其消费到后续的处理成功，只会发生一次 3\. at least once ：至少一次，表示一条消息从消费到后续的处理成功，可能会发生多次 在我们程序处理中通常要求能够满足exec
Flink-Exactly-once一致性系列实践2
feiyangailing的博客
03-25 2018
Flink-Exactly-once一致性系列实践2 这次是实现Kafa->mysql的记录哦
我们谈论的Exactly once到底是什么？
weixin_43167418的博客
01-11 6051
来自：掘金（作者：Flink_China）原文链接（底部链接可直达）：转自：https://juejin.cn/post/6844903857558913038英文原文：https://...
Kafka的Exactly-once语义与事务机制
lvlei19911108的博客
04-24 842
Kafka 0.11.x版本(对应 Confluent Platform 3.3)，该版本引入了exactly-once语义。精确一次确实很难实现(Exactly-once is a really hard problem)Mathias Verraes说，分布式系统中最难解决的两个问题是：消息顺序保证(Guaranteed order of messages)。消息的精确一次投递(Exactly...
硬核！八张图搞懂 Flink 端到端精准一次处理语义 Exactly-once（深入原理，建议收藏）
LLand520的博客
02-01 1485
Flink 在 Flink 中需要端到端精准一次处理的位置有三个： Source 端：数据从上一阶段进入到 Flink 时，需要保证消息精准一次消费。 Flink 内部端：这个我们已经了解，利用 Checkpoint 机制，把状态存盘，发生故障的时候可以恢复，保证内部的状态一致性。不了解的小伙伴可以看下我之前的文章： Flink可靠性的基石-checkpoint机制详细解析 Sink 端：将处理完的数据发送到下一阶段时，需要保证数据能够准确无误发送到下一阶段。 在 Flink 1.4 版本之前，精准一次处
flink读写kafka保证端到端exactly-once
yiweiyi329的博客
10-13 1849
flink读写kafka保证exactly-once
flink实现exactly-once
a3125504x的博客
11-08 805
flink实现exactly-once前言 前言 exactly-once，即实现一次且仅一次。可分为框架内实现和端对端实现。
两阶段提交(2PC)及其在Flink Exactly-once中的应用
微信搜：import_bigdata，大数据领域硬核原创作者
09-28 839
来源:jianshu.com/p/02d6d1103746作者:LittleMagic大数据技术与架构点击右侧关注，大数据开发领域最强公众号！暴走大数据点击右侧关注，暴走...
Flink HDFS Sink 如何保证 exactly-once 语义
http://www.54tianzhisheng.cn/
03-18 793
本文将从源码层面来分析在Flink中是如何保证sink数据到HDFS的exactly-once语义的。Flink中sink数据到HDFS是由Bucket...
Flink（四十四）—— Flink HDFS Sink 如何保证 exactly-once 语义
weixin_42073629的博客
10-21 894
本文将从源码层面来分析在Flink中是如何保证sink数据到HDFS的exactly-once语义的。 Flink中sink数据到HDFS是由BucketingSink来完成。BucketingSink产生的HDFS文件路径格式如下， /{base/path}/{bucket/path}/{part_prefix}-{parallel_task_index}-{count}{part_suffix} 其中， •{base/path}，构造BucketingSink时指定的base路径；•{bucke
正确理解二阶段提交（Two-Phase Commit）
热门推荐
萧萧的专栏
03-07 4万+
明确问题 二阶段提交出现的背景是， 当我们使用分布式系统时， 如果分布式系统中的机器发生故障之后， 如何保证事务数据的一致性。 从一个场景入手， 假设一个人要从 A 银行向 B 银行进行跨行转账 100 元。 此时我们需要对 A 银行数据库中该用户的账户，做金额扣减操作（ - 100）， 同时对 B 银行数据库中该用户的账户做金额增加操作 （ +100） 这两个操作( -100 和 + 100）...
Dsp28335与FPGA并行通信：高速数据传输与接收，实现PWM外扩功能的高效协同处理,Dsp28335 与FPGA的并行通信（最高速率150MHZ），可以将DSP数据传给FPGA的指定位置，以及从
01-27
Dsp28335与FPGA并行通信：高速数据传输与接收，实现PWM外扩功能的高效协同处理,Dsp28335 与FPGA的并行通信（最高速率150MHZ），可以将DSP数据传给FPGA的指定位置，以及从FPGA的指定位置读取数据到DSP。 对于DSP利用FPGA来外扩PWM非常实用方便 ,核心关键词：Dsp28335; FPGA; 并行通信; 高速率; 数据传输; DSP数据; 指定位置; PWM外扩。,DSP28335与FPGA高速通信：数据传输与外扩PWM的实用方案
Go语言并发编程教程：深入讲解 goroutine、channel 及 sync 包的应用与优化技巧
01-27
内容概要：本文全面介绍了Go语言的并发编程模型，重点探讨了 goroutine 和 channel 这两个关键组件及其详细应用案例，涵盖创建和使用 goroutine、不同类型的 channel、sync 包提供的并发工具，还包括生产者-消费者模型、工作池模式和管道模式等常见并发模式的具体实现与代码示例。此外，讨论了并发编程的最佳实践、高阶主题如死锁检测、性能优化等方面的内容。 适用人群：适用于有一定编程经验，特别是希望深入理解和掌握Go语言并发特性的开发者和技术爱好者。 使用场景及目标：学习本课程有助于程序员充分利用Go的并发优势构建高效的并发应用程序，提升多任务处理能力，并解决实际项目中遇到的并发挑战，例如实现数据共享、同步处理和提高程序响应速度。 其他说明：文中不仅提供理论知识讲解，还包含了丰富的真实编程实例帮助读者更好地理解概念，在实践中快速掌握Go并发编程的核心技能。
欧姆龙CP1H与力士乐VFC-x610变频器高效通讯程序：实现设定频率、控制正反转等多功能，注释完整、实用可靠 ,欧姆龙CP1H与力士乐VFC-x610变频器通讯程序功能：原创程序，可直接用于现场程序
01-27
欧姆龙CP1H与力士乐VFC-x610变频器高效通讯程序：实现设定频率、控制正反转等多功能，注释完整、实用可靠。,欧姆龙CP1H与力士乐VFC-x610变频器通讯程序功能：原创程序，可直接用于现场程序。 欧姆龙CP1H的CIF11通讯板，实现对力士乐VFC-x610变频器 设定频率，控制正反转，读取实际频率，读取输出电压，变频器状态功能。 反应灵敏，通讯稳定可靠。 后续可根据需要扩展台数时，非常灵活方便。 器件：欧姆龙CP1H，CP1W CIF11串口网关板，3台力士乐VFC-x610变频器，昆仑通态TPC7062KD触摸屏。 说明：是程序，带注释，带变频器手册，接线，参数设置都提供。 通讯稳定可靠，实用有效。 ,欧姆龙CP1H; 力士乐VFC-x610变频器; 通讯程序; 设定频率; 控制正反转; 读取实际频率; 读取输出电压; 变频器状态; 反应灵敏; 器件扩展; 昆仑通态TPC7062KD触摸屏。,欧姆龙CP1H与力士乐VFC-x610变频器通讯程序：高效稳定，功能全面升级
基于卷积神经网络的子 宫内膜 癌 分类问题.pdf
最新发布
01-27
基于卷积神经网络的子 宫内膜 癌 分类问题.pdf
八张图搞懂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?
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值