Flink容错的核心机制就是持续地创建分布式数据流及其状态的一致性快照,。当系统遇到故障时,比如(机器,网络,软件等),重启所有的算子,回退到checkpoint(检查点),确保程序的每一条记录只会作用准确一次(exactly-once )的语义,也可以选择配置成至少一次(at-least-once )
注意: 为了容错机制生效,数据源(例如 queue 或者 broker)需要能重放数据流。比如说Apache Kafka, Flink 中 Kafka 的 connector 利用了这个功能。
简单来说: Flink的容错机制就是 检查点机制+可部分重发的数据源
异步屏障快照是一种轻量级的快照技术,能以低成本备份 DAG(有向无环图)或 DCG(有向有环图)计算作业的状态,这使得计算作业可以频繁进行快照并且不会对性能产生明显影响。异步屏障快照核心思想是通过屏障消息(barrier)来标记触发快照的时间点和对应的数据,从而将数据流和快照时间解耦以实现异步快照操作,同时也大大降低了对管道数据的依赖,减小了随之而来的快照大小。
Flink的checkpoint机制实现了标准的 Chandy-Lamport 算法,并且用来实现分布式快照。
Barrier的中文释义叫做数据栅栏或者屏障,顾名思义,是用来分隔数据的。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-iqgfCjDz-1577256469103)(https://s2.ax1x.com/2019/12/24/lCcmc9.png)]
上面说的是单个流的barrier,那如果有多个输入流呢,就需要进行barrier对齐
下图是执行保存检查点的第一步,左侧代表一个检查点协调者,中间是由两个source和一个sink组成的flink作业,最后侧是持久化存储(HDFS)
source在数据流中插入了barrier后,数据流向下游流动,同时把自己的状态异步的写入持久化存储中
当task完成state的备份之后,会将备份数据的地址(state handle)通知给检查点协调者
当些有的sink节点收集齐上游的两个输入流的barrier之后,执行本地快照,以RocksDB 增量式的Checkpoint 为例,首先 RocksDB 会全量刷数据到磁盘上(红色大三角表示),然后 Flink 框架会从中选择没有上传的文件进行持久化备份(紫色小三角)。
sink节点完成自己的Checkpoint 之后,也会返回state handle 给检查点协调者
当检查点协调者收集齐所有的state handle之后,就认为本次Checkpoint 全局完成了,向持久化存储中再备份一个 Checkpoint meta 文件。
检查点有两种类型,分别为
Savepoint
Checkpoint
Savepoint | Externalized Checkpoint |
---|---|
用户通过命令触发,由用户管理其创建与删除 | Checkpoint 完成时,在用户给定的外部持久化存储保存 |
标准化格式存储,允许作业升级或者配置变更 | 当作业 FAILED(或者 CANCELED)时,外部存储的 Checkpoint 会保留下来 |
用户在恢复时需要提供用于恢复作业状态的 savepoint 路径 | 用户在恢复时需要提供用于恢复的作业状态的 Checkpoint 路径 |
所谓容错,就是在作业任务挂掉之后,重新执行时,能够恢复到作业挂掉之前的状态,并且为了保证准确一次(exactly once )的语义,要求作业从失败恢复后的状态要和失败时一致,而恢复时就是根据检查点的快照进行恢复。
注意: 如果是RockDB的增量快照,operator 需要从最新的全量快照回复,然后对此状态进行一系列增量更新。