31.Flink容错机制介绍

Leefs 2022-02-13 PM 1570℃ 0条

[TOC]

### 前言

作为分布式系统，尤其是对延迟敏感的实时计算引擎，Apache Flink 需要有强大的容错机制，以确保在出现机器故障或网络分区等不可预知的问题时可以快速自动恢复并依旧能产生准确的计算结果。

事实上，Flink 有一套先进的快照机制来持久化作业状态，确保中间数据不会丢失，这通常需要和错误恢复机制配合使用。

在遇到错误时，Flink 作业会根据重启策略自动重启并从最近一个成功的快照（checkpoint）恢复状态。

### 一、容错机制

**容错机制**对分布式流式数据持续性的产生**快照**(`snapshot`)并存储。对于持有小型数据状态的数据流应用来说，产生快照的过程是很轻量级的，对于数据流的正常处理过程的影响微乎其微。数据流应用的**状态**数据可以存储到一个可配置的环境(`Master`节点中，或者 `HDFS` 中）。

当程序失败（机器、网络或者软件故障）的时候，`Flink` 将停止分布式数据流应用。然后再从最后一次成功的 `checkpoint` 中保存的**状态**(`state`) 数据中恢复应用的所有**算子**（`Operator`）。输入数据也被重置到最后一次成功的**快照**数据中保存的位置 。 `Flink` 保证并行数据流在重启之后处理的所有数据都不会是最近一次成功的 `checkpoint` 之前的数据。

**注意**

+ `checkpointing` 功能默认是关闭的，需要手动配置，指定开启 `checkpointing`；
+ 在 `Flink` 完成保证的基础上，数据流输入源 (`streaming source`)需要保障能回退到指定的最近一个位置。

#### Checkpointing

`Flink` 的**容错机制**简而言之就是持续不断的对**分布式数据流**和**算子状态(Operator state)**产生**一致性**的**快照**数据。这些**快照**数据系统遇到故障时，用于从错误状态中恢复的**检查点** (`checkpoints`)。

Checkpoint算法是在参考 Chandy-Lamport algorithm算法的基础上进行改进的，并针对**Flink 执行模型**进行量身定做。

### 二、Barriers（栅栏）

+ `Flink` 的分布式快照的核心组成部分就是 `Barriers(栅栏)`，这些 `Barriers(栅栏)` 被插入到数据流中，和数据一起往下流。
+ `Barriers(栅栏)` 不会影响数据流中数据的顺序，数据流保证严格有序。

+ `Barriers(栅栏)` 将数据切分成两部分，前一部分的数据进入当前的快照数据(`snapshot`)中，后一部分的数据进入下一快照数据。
+ 每个 `Barriers(栅栏)` 都有一个 `ID`，这个 `ID` 就是 `Barriers(栅栏)` 前一个 `snapshot` 的 `ID`。
+ `Barriers(栅栏)` 不会影响数据流的处理，所以非常轻量级。
+ 多个不同 `快照` 的多个 `Barriers(栅栏)` 可以在数据流中同时存在，即多个 `快照` 可以同时创建。

从下图看，数据是从左向右移动（右边的先进入系统），那么快照n包含的数据就是右侧到下一个屏障（n-1）截止的数据，图中两个灰色竖线之间的部分，也就是`part of checkpoint n`。

另外屏障并不会打断数的流动,因而屏障是非常轻量的。在同一个时刻，多个快照可以在同一个数据流中，这也就是说多个快照可以同时产生。

![31.Flink容错机制介绍01.png](https://lilinchao.com/usr/uploads/2022/02/2950185041.png)

如果是多个输入数据流，多个数据流的屏障会被同时插入到数据流中。快照n的屏障被插入到数据流的点（我们称之为Sn），就是数据流中一直到的某个位置（包含了当前时刻之前时间的所有数据），也就是包含的这部分数据的快照。举例来说，在Kafka中，这个位置就是这个分区的最后一条记录的offset。这个位置Sn就会上报给 checkpoint 的协调器（Flink的 JobManager）。

然后屏障开始向下流动。当一个中间的operator收到它的所有输入源的快照n屏障后，它就会向它所有的输出流发射一个快照n的屏障，一旦一个sink的operator收到所有输入数据流的屏障n，它就会向checkpoint的协调器发送快照n确认。当所有的sink都确认了快照n，系统才认为当前快照的数据已经完成。

一旦快照n已经执行完成，任务则不会再请求Sn之前的数据，因为此刻，这些数据都已经完全通过了数据流拓扑图。

#### 对齐机制

接收不止一个数据输入的operator需要基于屏障**对齐**输入数据流。

在有多个输入 Channel 的情况下，为了数据准确性，算子会等待所有流的 Barrier 都到达之后才会开始本地的快照，这种机制被称为 Barrier 对齐。

在对齐的过程中，算子只会继续处理的来自未出现 Barrier Channel 的数据，而其余 Channel 的数据会被写入输入队列，直至在队列满后被阻塞。当所有 Barrier 到达后，算子进行本地快照，输出 Barrier 到下游并恢复正常处理。

比起其他分布式快照，该算法的优势在于辅以 Copy-On-Write 技术的情况下不需要 “Stop The World” 影响应用吞吐量，同时基本不用持久化处理中的数据，只用保存进程的状态信息，大大减小了快照的大小。

![31.Flink容错机制介绍02.png](https://lilinchao.com/usr/uploads/2022/02/1094273866.png)

**说明**

+ **图左一**：**当operator接收到快照的屏障n后并不能直接处理之后的数据，而是需要等待其他输入快照的屏障n。否则话，会将快照n的数据和快照n+1的数据混在一起。**

在左边第一个图中operator即将要收到数据流1(上面这个我们当成数据流1（6，5，4，3，2，1），下面的当成数据流2)的屏障n，1，2，3在屏障n之后到达operator，这个时候如果数据流1的继续处理，那么operator中就会包含n屏障之后的数据（1，2，3），但是operator中此刻在接收和处理数据流2，数据（a,b,c）就会和数据流1中的（1，2，3）混合。

+ **图左二**：**快照n的数据流会被暂时放到一边。从这些数据流中获取到的数据不会被处理，而是存储到一个缓冲中。**

图中第一个所示，因为数据流2的屏障n还没到，所以operator持续接收1，2，3然而并不做任何处理。但是需要将1，2，3存入到buffer中。此时第二个数据流接到a，b，则直接发送，接到c发送c。

+ **图左三**：**一旦最后一个数据流收到了快照n，opertor就会将发出所有阻塞的数据，并发出自己的屏障。**

如图中第三个所示，operator最后收到了另一个数据流的屏障n，然后再发出a,b,c(图中operator中的c,b,a)以后，发出自己的屏障，这个时候buffer中又增加了一个4，变成（4，3，2，1）。

+ **图左四**：之后operator会重新开始处理所有的输入数据流，先处理buffer中的数据，处理完之后再处理输入数据流的数据。

如图第四个所示，先将buffer中的1，2，3，4先处理完，在接收并处理这两个数据源的数据。

*附参考文章链接：*

*[深入理解 Flink 容错机制](http://www.whitewood.me/2019/07/28/%E6%B7%B1%E5%85%A5%E7%90%86%E8%A7%A3-Flink-%E5%AE%B9%E9%94%99%E6%9C%BA%E5%88%B6/)*

*[Flink 的容错机制](https://summerbuger.github.io/2019/01/26/%E6%8A%80%E6%9C%AF/flink/flink%E4%B9%8Bsavepoints%E5%92%8Ccheckpoints/)*

标签: Flink

非特殊说明，本博所有文章均为博主原创。

如若转载，请注明出处：https://lilinchao.com/archives/1891.html

上一篇 30.Flink状态一致性

下一篇 32.Flink Checkpoint配置

31.Flink容错机制介绍

评论已关闭

栏目分类

标签云

友情链接申请

31.Flink容错机制介绍

评论已关闭

 栏目分类

标签云

友情链接申请

栏目分类

标签云

友情链接申请