flink checkpoint时exact-one模式和atleastone模式的区别

文章讨论了ApacheFlink流处理引擎中checkpoint的exact-one和at-least-one模式的区别,exact-one确保状态一致性,at-least-one可能导致重复处理。at-least-one仅在无需对齐操作的简单算子场景下可能接近exact-one效果。

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

背景:

flink在开启checkpoint的时候有两种模式可以选择,exact-one和atleastone模式,那么这两种模式有什么区别呢?

exact-one和atleastone模式的区别

先说结论:exact-one可以完全做到状态的一致性,而atleastone模式正常情况下没法做到状态的一致性,如果开启这个模式,有些消息会重复处理,例如统计计数时,重复的消息会导致统计两次
那么为什么会这样呢?原理如下:
在这里插入图片描述

简单来说,主要的区别在于两种模式下对于接收到ckp分隔符后对齐过程中是否继续处理已经收到ckp分隔符的chanel的记录的不同,exactone是ckp分隔符对齐过程中先缓存记录不处理,而atleastone在ckp分隔符对齐过程中正常处理消息,这样这些消息就会被当成这次ckp的状态的一部分,而其实它不应该是这次ckp状态的一部分,而在应用从最新的ckp启动后,这些记录又有重新消费,叠加上之前已经成为ckp状态的那一次,相当于消息被重复处理了两次,所以才被称为atleastone模式

彩蛋:那么atleastone有可能达到exactone一样的效果吗?

有,前提是作业不需要包含对齐操作,也就是比如只包含map,fliter等并行算子,完全不需要分隔符对齐,但是这种情况下应该直接设置为exactone就完事了,不用故意使用atleastone的

### Flink 的三种一致性语义 #### At-Least-Once (至少一次) At-Least-Once 语义确保每条记录至少被处理一次。这意味着,在发生故障并重启之后,某些记录可能会被重复处理。这种语义适用于那些对数据准确性有一定容忍度的应用场景。 为了实现这一目标,Flink 使用了检查点机制来定期保存应用程序的状态。当系统遇到失败,可以从最近的一个检查点恢复,并重新处理自该检查点以来的所有输入流[^4]。 ```python env = StreamExecutionEnvironment.get_execution_environment() env.set_restart_strategy(RestartStrategies.fixed_delay_restart( attempts=3, delay_between_attempts_ms=1000)) ``` #### At-Most-Once (最多一次) At-Most-Once 是指每条消息要么被成功处理过零次或仅一次。然而,如果在处理过程中出现了错误,则可能导致部分未完成的消息丢失。因此,这类语义通常用于实分析等场合下,其中少量的数据损失是可以接受的。 在这种模式下,Flink 不会启用任何额外的功能来进行状态管理或者容错处理;它只是简单地读取来自源头的数据并通过转换操作传递给下游组件。 ```python env = StreamExecutionEnvironment.get_execution_environment() env.disable_checkpointing() # 关闭checkpoint功能以达到at-most-once效果 ``` #### Exactly-Once (恰好一次) Exactly-Once 提供最强健的一致性保障——即保证每个事件都被准确无误地处理了一次且仅有这一次。这往往是最理想的状况,但在实际部署中可能面临更多挑战,因为要确保整个链路从数据源到接收端都能支持这样的特性。 对于 Flink 而言,通过其内置的支持两阶段提交协议(Two-phase commit protocol)以及与外部系统的集成能力,可以在很多情况下达成 End-to-End Exact Once Semantics[^1]。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值