0


简单总结:Flink和Kafka是如何做到精准一致性的

Flink CheckPoint机制

CheckPoint本质上就是检查点,类似于玩游戏的时候,需要偶尔存档,怕家里断电导致自己白玩。
在这里插入图片描述

Flink也是一样的,机器也是可能宕机,那么Flink如何保证自身不受宕机影响呢?

一般来说,存档有两种策略,一种是“随时”,即处理完一条数据就存档一次,这样保证了数据的高可用,但是会对系统带来巨大的性能损失,而且机器宕机是一个小概率事件。

另外一种就是周期性存档,即每过一段事件,就存档一次,flink采用的就是这种


听起来很简单,但还有一个问题,周期性触发存档的时候,如果正好在处理一个数据,这时候怎么办?

  • 停止处理数据,进行存档:这种是肯定不行的,因为任务正在处理,你不知道处理到什么状态了,你只能把所有的状态信息都存下来,这很麻烦的。
  • 把正在处理的数据处理完,再进行存档:这听起来不错,但是分布式系统的节点之间需要通过网络通信来传递数据,如果我们保存检查点的时候刚好有数据在网络传输的路上,那么下游任务是没法将数据保存起来的;故障重启之后,我们只能期待上游任务重新发送这个数据。然而上游任务是无法知道下游任务是否收到数据的,只能盲目地重发,这可能导致下游将数据处理两次,结果就会出现错误。

怎么解决?

我们的策略是:当所有任务都恰好处理完一个相同的输入数据的时候,将它们的状态保存下来。首先,这样避免了除状态之外其他额外信息的存储,提高了检查点保存的效率。
其次,一个数据要么就是被所有任务完整地处理完,状态得到了保存;要么就是没处理完,状态全部没保存:这就相当于构建了一个“事务”(transaction)。如果出现故障,我们恢复到之前保存的状态,故障时正在处理的所有数据都需要重新处理;所以我们只需要让源(source)任务向数据源重新提交偏移量、请求重放数据就可以了。这需要源任务可以把偏移量作为算子状态保存下来,而且外部数据源能够重置偏移量;

Kafka 就是满足这些要求的一个最好的例子,比如下面,我们以一个wordCount任务流程为例,一个正常的检查点保存机制是怎样的:

在这里插入图片描述

源任务处理了三条数据,下游任务也完成了对这三条数据的处理,所以符合我们的策略(当所有任务都恰好处理完一个相同的输入数据的时候,进行存档)


我们来看下故障状态下的处理流程,当源任务又完成处理了2条数据时,偏移量变成了5,但是在求和任务时,宕机了,这时候根据我们的策略,这2条数据没有被所有的数据完成,那么我们就不会在外部存储我们的状态
在这里插入图片描述
即我们已经持久化保存的状态是这样的:
在这里插入图片描述

当应用重启的时候,我们根据这个检查点状态进行恢复就可以,但是这样有个问题,对源算子来说,任务已经完成,4,5偏移量对应的数据已经给你下游发过去了,我又不知道你失败了

这种情况下我们的策略就很有优势,我们只需要根据检查点保存的偏移量,重置上游数据源任务的偏移量,要求进行重放数据就可以。

所以,如果要保证精准一次性,上游组件必须支持数据重放,kafka就支持。

现在来看,文章标题是不是就明白了。

标签: kafka flink 大数据

本文转载自: https://blog.csdn.net/weixin_43889841/article/details/128511382
版权归原作者 May Hacker 所有, 如有侵权,请联系我们删除。

“简单总结:Flink和Kafka是如何做到精准一致性的”的评论:

还没有评论