Java教程

Flink-容错机制-检查点原理和算法

本文主要是介绍Flink-容错机制-检查点原理和算法,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!

一、一致性检查点(Checkpoints)

Flink故障恢复机制的核心,就是应用状态的一致性检查点 有状态流应用的一致性检查点,其实就是所有任务的状态,在某个时间点的一份拷贝(一份快照);这个时间点,应该是所有任务都恰好处理完一个相同的输入数据的时候  

二、从检查点恢复状态

  在执行流应用程序期间,Flink会定期保存状态的一致检查点 如果发生故障,Flink将会使用最近的检查点来一致恢复应用的状态,并重新启动处理流程   上图示例:6已处理完,正要处理7,发现任务挂了 第一步:就是重启应用   第二步:是从checkpoint中读取状态,将状态重置 从检查点重新启动应用程序后,其内部状态与检查点完成时的状态完全相同 从5之后的offset处开始消费读取   第三步:开始消费并处理检查点到发生故障之间的所有数据 这种检查点的保存和恢复机制可以为应用程序状态提供”精确一次“(Exactly-once)的一致性,因为所有算子都会保存检查点并恢复其所有状态,这样一来所有的输入流都会被重置到检查点完成时的位置  

三、检查点的实现算法

Flink基于Chandy-Lamport算法的分布式快照(在某个数据后插入一个标记位,执行到此的时候做一次checkpoint) 将检查点的保存和数据处理分离开,不暂停整个应用   检查点分界线(Checkpoint Barrier) Flink的检查点算法用到了一种称为分界线(barrier)的特殊数据形式,用来把一条流上数据按照不同的检查点分开 分界线之前到来的数据导致的状态更改,都会被包含在当前分界线所属的检查点中;而基于分界线之后的数据导致的所有更改,就会被包含在之后的检查点中 JobManager控制分界线,插入分界线命令只发给source   现在是一个有两个输入流的应用程序,用并行的两个source任务来读取   JobManager会向每个source任务发送一条带有新检查点ID的消息,通过这种方式来启动检查点 source任务在当前数据处理完成之后,就会在这条数据之后插入一个barrier   数据源将它们的状态写入检查点,并发出一个检查点barrier 状态后端在状态存入检查点之后,会返回通知给source任务,source任务就会向JobManager确认检查点完成 并发source任务将各自目前已处理完的数据进行保存,并告知JobManager检查点已存储完成,barrier并向下游广播出去,后续任务还在执行   分界线对齐:barrier向下游传递,sum任务会等待所有输入分区的barrier到达 对于barrier已经到达的分区,继续到达的数据会被缓存;而barrier尚未到达的分区,数据会被正常处理   当收到所有输入分区的barrier时,任务就将其状态保存到状态后端的检查点中,然后将barrier继续向下游转发   向下游转发检查点barrier后,任务继续正常的数据处理
这篇关于Flink-容错机制-检查点原理和算法的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!